Skip to main content
Glama

create_rfi

Raise a numbered RFI when the drawing set contradicts itself — mismatched tags, finishes, or scales — and log the question in the estimator's register for the architect to answer.

Instructions

Raise an RFI — a Request For Information — when the drawing set contradicts itself or cannot answer a question you need answered to take the work off: a room-finish schedule row that names a tag the plan never draws, a room label the schedule has no row for, a finish called out two ways, a scale that disagrees with a stated dimension. It lands in the estimator's RFI register (the canvas's RFI panel) with the next number in that register's own sequence (RFI-001, RFI-002, …), status open, dated today, on the sheet you name. You raise it as the agent: the record carries origin {actor: "agent", reviewed: false} and is PENDING — pencil — until the estimator accepts it in the register, because an RFI goes to the architect and nothing sends without a human. It still prints in the marked set's RFI schedule like any other RFI, so the question is on the deliverable. Pass markup_ids to pin it to annotations already on the sheet (annotate a cloud or callout at the conflict first, then link it here) — a linked markup carries the RFI number on the canvas and in the marked set, and list_rfis reports which finish tags the question touches through those links. Prefer this to describing the conflict in prose: a question in the register is tracked, numbered, and answered; a sentence in a reply is lost. Journaled; undo_last takes it back.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
sheetYesSheet name or number the question is about, as sheet_info reports it
titleYesThe one-line subject the register and the RFI schedule print — what the question is about
questionYesWhat you are asking the architect to answer, stated so a reply can settle it
markup_idsNoAnnotation ids (annotate / list_annotations) to link — they carry this RFI's number on the sheet

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
idYesThe record id ("rfi-…")
dateYesYYYY-MM-DD opened
noteYes
actorYesWho raised it — "agent" for every RFI minted over MCP, "estimator" for a panel-raised one
sheetYesThe sheet the question is about
numberYesThe register number, "RFI-001" — next in the panel's own sequence, never reissued
statusYesThe panel's lifecycle: open → answered → closed; void = withdrawn
pendingYestrue = agent-raised and not yet accepted by an estimator in the register (origin.reviewed false) — pencil, not sent
subjectYes
questionYes
responseYes
conditionsYesFinish tags the linked markups are attached to — the scopes this question touches
response_dateYesYYYY-MM-DD answered, '' while open
linked_markupsYesAnnotation ids carrying this RFI's number on the sheet (markup.rfi_id) — derived, never stored twice

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.1.21

TDQS

A4.7/5.0
Behavior5/5

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

With no annotations, the description fully carries the behavioral burden: it discloses the register sequence (RFI-001, …), default status ('open'), date handling, the agent origin record and 'PENDING' state pending human acceptance, printing behavior in the marked set, markup linking effects, and that the action is journaled and undoable. This is exceptionally thorough for a mutation tool.

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?

The description is dense but every sentence earns its place: it front-loads purpose and conditions, then systematically covers behavior, linking, and journaling. There is no filler or repetition, and the information is logically ordered for an agent.

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

Completeness5/5

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

Given the absence of annotations and the presence of an output schema (which handles return values), the description provides all necessary context for correct invocation: when to use it, how it behaves, what state it creates, and how linked markups affect downstream reporting. Nothing critical is missing.

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 significant meaning for markup_ids (explaining how to link annotations and the resulting RFI number propagation) but adds little beyond the schema for title, question, and sheet. The net value beyond structured data is moderate.

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?

The description opens with a precise verb+resource ('Raise an RFI') and immediately defines the specific conditions for its use, distinguishing it from prose or other tracking methods. The detailed scenario examples make the purpose unmistakable without opening the 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?

It clearly states when to use the tool ('when the drawing set contradicts itself or cannot answer a question') and explicitly prefers it over describing the conflict in prose. However, it does not name an alternative sibling tool (e.g., resolve_rfi or list_rfis) for related tasks, so the routing guidance is strong but not exhaustive.

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