Skip to main content
Glama

Portravo Construction Takeoff

Attach a construction plan PDF

attach_plan_pdf
Idempotent

Attach a PDF the user selected in this conversation as the first plan for a new Portravo project. Plan PDFs must be 10 MiB or smaller. Accepts exactly one of plan, a host-provided download_url and file_id, or plan_inline, canonical base64 of the exact user-uploaded PDF bytes with file_name and application/pdf mime_type, up to 32 KiB. A PDF with no file link above 32 KiB, or any PDF above the direct limit, is uploaded in the browser at the project's reviewUrl instead. That browser path streams up to 50 MiB for the selected automatic trades. Projects that already have a plan or review work are refused, so existing work is never replaced. Repeating a call with the same idempotency_key returns the original result. Stores the selected PDF privately in the connected account; does not extract or consume credits.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
planNoHost-provided signed file link for a PDF the user attached (PDF up to 10 MiB).
project_idYes
plan_inlineNoExact bytes of a user-uploaded PDF as canonical base64, only when no file link exists. PDF up to 32 KiB.
idempotency_keyYes

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
statusYes
reviewUrlYes
planFileIdYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • addedInput schema / properties / plan / description
      Added value: +"Host-provided signed file link for a PDF the user attached (PDF up to 10 MiB)."
    • addedInput schema / properties / plan_inline / description
      Added value: +"Exact bytes of a user-uploaded PDF as canonical base64, only when no file link exists. PDF up to 32 KiB."
  2. Changed3 schema fields changed
    • addedInput schema / oneOf
      Added value: +[
      +  {
      +    "not": {
      +      "required": [
      +        "plan_inline"
      +      ]
      +    },
      +    "required": [
      +      "plan"
      +    ]
      +  },
      +  {
      +    "not": {
      +      "required": [
      +        "plan"
      +      ]
      +    },
      +    "required": [
      +      "plan_inline"
      +    ]
      +  }
      +]
    • addedInput schema / properties / plan_inline
      Added value: +{
      +  "additionalProperties": false,
      +  "properties": {
      +    "data_base64": {
      +      "maxLength": 43692,
      +      "minLength": 4,
      +      "type": "string"
      +    },
      +    "file_name": {
      +      "maxLength": 200,
      +      "minLength": 5,
      +      "pattern": "^[^/\\\\\\x00-\\x1f]+\\.pdf$",
      +      "type": "string"
      +    },
      +    "mime_type": {
      +      "const": "application/pdf",
      +      "type": "string"
      +    }
      +  },
      +  "required": [
      +    "data_base64",
      +    "mime_type",
      +    "file_name"
      +  ],
      +  "type": "object"
      +}
    • changedInput schema / required
      Previous value: -[
      -  "project_id",
      -  "plan",
      -  "idempotency_key"
      -]New value: +[
      +  "project_id",
      +  "idempotency_key"
      +]
  3. First observed

TDQS

A4.5/5.0
Behavior5/5

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

Discloses behavior beyond the annotations: projects that already have a plan or review work are refused so existing work is never replaced, storage is private in the connected account, no credits are consumed, and the fallback browser path streams up to 50 MiB. The refusal and no-credit semantics are not derivable from the annotations and directly affect agent decision-making.

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 action and the branch-selection rule, and every sentence carries operational weight. It is dense with size-limit details (10 MiB, 32 KiB, 50 MiB) that are useful but make the passage slightly sprawling.

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 not be described, and the description covers the tricky parts of a complex oneOf union: branch selection, size limits, idempotent replay, and refusal on non-empty projects. Only minor surface area (project_id meaning, what reviewUrl resolves to) is left implicit.

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 coverage is 50%, so the description must compensate and largely does: it explains the oneOf union (exactly one of plan vs plan_inline), the download_url/file_id pairing, and the base64/mime_type/file_name composition of plan_inline. project_id remains unexplained, keeping it below a full 5.

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 specific verb (attach) plus resource (construction plan PDF) and scope (as the first plan for a new Portravo project). An agent can distinguish this from every sibling, none of which attach or ingest plan files, 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?

Gives clear usage conditions: only PDFs the user selected in this conversation, with explicit size thresholds (10 MiB direct, 32 KiB inline) and a routing rule to the browser reviewUrl path when over the inline limit. It stops short of naming sibling alternatives, but the when-to-use context is concrete and usable.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources