va-lis-mcp

list_most_viewed_bills

The bills of a session that readers of the LIS website open most often.

Instructions

The bills of a session that readers of the LIS website open most often.

LIS sends at most 100, in its own order, with the same fields as search_bills. The list measures public attention, not legislative weight.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "session_code": "<session_code>"
    },
    "name": "list_most_viewed_bills"
  }
}

Input Schema

Name	Required	Description	Default
`limit`	No
`session_code`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Addedv0.2.0Oct 13, 2026

TDQS

A3.5/5.0

Behavior4/5

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

With no annotations, the description carries the full burden and does disclose real behavior: results are capped at 100, returned in LIS's own order (i.e., no caller-controlled sorting), and carry the same fields as search_bills. It does not say how limit interacts with the 100 cap or whether results paginate.

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?

Three terse lines with zero filler, and the core identity of the list is stated first. Every sentence adds a fact: what it measures, the cap/ordering, and field parity.

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

Completeness3/5

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

For a two-parameter read tool with no annotations and no output schema, the description covers ordering, cap, and return fields adequately, but leaves limit semantics and session_code format unexplained. Reasonably complete, with a clear gap on the single optional parameter.

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

Parameters2/5

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

Schema description coverage is 0%, so the description must compensate. It conveys the meaning of session_code indirectly ('bills of a session') but never explains the limit parameter, its default of 25, or its relationship to the stated 100-item ceiling.

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?

States a specific resource and scope: bills of a given session ranked by how often LIS site readers open them. The clause 'measures public attention, not legislative weight' distinguishes it semantically from list_bills/search_bills, even though it doesn't name an alternative outright.

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

Usage Guidelines3/5

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

No explicit when-to-use or when-not-to-use statement, and no alternative is named as a routing option. Usage is only implied by the semantic note that this reflects popularity rather than legislative importance, which lets an agent infer it is a 'what's trending' list rather than a search tool.

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