congress_congressional_record

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

The readOnlyHint annotation already covers the safety profile, so the description only needs to add behavioral context beyond that. It adds the date-filtering scope but does not disclose edge cases like missing issues for a date, pagination behavior, or whether multiple issues per day are returned. This is adequate but not rich.

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

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

The description is two sentences long: the first clearly states the tool's purpose, and the second briefly explains the filtering capability. Every sentence contributes value, and the verb-first structure makes it immediately scannable.

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

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

Given the readOnlyHint and complete schema, the description provides enough context for a straightforward lookup tool. However, it lacks any mention of how this tool relates to the daily/bound congressional record siblings, and without an output schema, it does not describe the return format. For a simple retrieval tool, this is mostly complete but could be more precise.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema already describes all four parameters (day, year, limit, month) with 100% coverage, so the baseline is 3. The description rephrases 'filter by year, month, and day' without adding new meaning beyond the schema, and omits the limit parameter entirely, which is documented only in the schema.

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

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

The description clearly states the tool retrieves Congressional Record issues, identifying it as the official daily record with date-based filtering. However, it does not differentiate this tool from closely related siblings like 'congress_daily_congressional_record' or 'congress_bound_congressional_record', which weakens its distinctiveness among the congress_* tool family.

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

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

The description implies when to use the tool (when you need Congressional Record issues by year/month/day) but provides no explicit alternatives or exclusions. With many congress-related siblings, the absence of guidance on choosing between this and the daily/bound variants is a clear gap.

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