Skip to main content
Glama
Sign In
opentakeoff-mcp

opentakeoff-mcp

by Kentucky-ai
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

list_rfis

List every RFI in the register with status, sheet, raiser, linked markups, finish tags, and withdrawn numbers so you can check existing questions and explain sequence gaps before raising a new one.

Instructions

Every RFI in the register with its status, sheet, who raised it (actor) and whether an agent-raised one is still pending the estimator's acceptance, its linked markup ids, and the finish tags those markups are attached to — the scopes the question touches. withdrawn[] lists the numbers delete_rfi tombstoned, so a gap in the sequence is explained rather than silent. Read this before raising a question the register already holds.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "list_rfis"
  }
}

Input Schema

NameRequiredDescriptionDefault

No arguments

Output Schema

NameRequiredDescriptionDefault
openYesStill awaiting an answer
rfisYesEvery live RFI, register order
countYes
pendingYesAgent-raised and not yet accepted by an estimator
withdrawnYesNumbers of withdrawn RFIs (delete_rfi tombstones) — the gaps in the sequence, explained

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed6 schema fields changedv0.1.31
    • addedOutput schema / properties / count / maximum
      Added value: +9007199254740991
    • addedOutput schema / properties / count / minimum
      Added value: +-9007199254740991
    • addedOutput schema / properties / open / maximum
      Added value: +9007199254740991
    • addedOutput schema / properties / open / minimum
      Added value: +-9007199254740991
    • addedOutput schema / properties / pending / maximum
      Added value: +9007199254740991
    • addedOutput schema / properties / pending / minimum
      Added value: +-9007199254740991
  2. Addedv0.1.21

TDQS

A4.3/5.0
Behavior4/5

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

No annotations are supplied, so the description carries the burden, and it does well: it discloses that the tool is a read operation, that tombstoned entries appear in withdrawn[] rather than being silently omitted, and that agent-raised RFIs may still be pending estimator acceptance. It does not mention ordering of the sequence or permissions, which are the remaining minor gaps.

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-loaded with the core statement and free of filler, but the opening sentence is a long, heavily compounded clause chain that takes effort to parse. The information density is justified; the syntax could be less tangled.

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?

An output schema exists, so return values need no further explanation, and with zero parameters there are no calling preconditions to document. The description adds the non-obvious semantics (pending acceptance, tombstoned numbers) that the schema would not convey, leaving only minor items like ordering unstated.

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 the schema imposes nothing to explain and the baseline applies. The description instead spends its words on the shape of the returned data, which is the useful place to spend them here.

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 concrete verb and resource ('every RFI in the register') and enumerates exactly what is returned: status, sheet, actor, agent-raised pending flag, linked markup ids, finish tags, and withdrawn[]. It is unmistakably distinct from create_rfi, resolve_rfi, and delete_rfi, which appear in the sibling list.

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?

Explicitly directs the agent to 'read this before raising a question the register already holds,' which routes it toward this tool ahead of create_rfi and implies duplicate-checking. It also explains that withdrawn[] covers numbers removed by delete_rfi. It stops short of naming alternatives by name, so it is strong context rather than a full when/when-not matrix.

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