Skip to main content
Glama
Sign In
veilform

veilform

by asteby
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

Collect any values blindly (forms, tables, CSV)

blind_input

Gather sensitive data via a local browser form without the AI seeing values, then send it directly to approved sinks and return only structural results.

Instructions

Generic blind input: send ONLY a schema (sections, typed fields, validations, showIf conditions, repeaters/tables with CSV import) and a sink (store, http, sql, file, ops-dataload, callback). The person fills the local page; values go directly to the sink. You receive {request_id, status, rows_written, ids, stored, keys, field_errors:[{field, code}]} and never values. Non-store sinks need the person's explicit approval on the same page (it shows the template with ${field} placeholders). Use blind_input_preview first to validate a complex schema.

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": {
      "title": "<title>",
      "schema": "<schema>",
      "sink": "<sink>"
    },
    "name": "blind_input"
  }
}

Input Schema

NameRequiredDescriptionDefault
sinkYes
titleYes
schemaYes
metadataNo
descriptionNo
submit_labelNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.5/5.0
Behavior5/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 it well: it discloses that values never reach the agent, that only metadata ({request_id, status, rows_written, ids, stored, keys, field_errors}) is returned, and that non-store sinks surface a template with ${field} placeholders requiring the person's approval. These are exactly the behavioral facts an agent needs for a no-annotation tool.

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?

Four tight sentences, front-loaded with the core mechanic and closing with the preview recommendation. Dense but every sentence carries information; only the sink enumeration slightly bloats the opener.

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?

For a complex, deeply nested tool with no output schema, the description supplies the return shape and the approval behavior, which is essential. It omits any mention of metadata/expiry or size limits, a minor residual gap against the very large schema.

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 0%, so the description must compensate, and it does for the two key parameters: it enumerates schema capabilities (sections, typed fields, validations, showIf, repeaters with CSV import) and sink types (store, http, sql, file, ops-dataload, callback). It adds no meaning for metadata, description, or submit_label, leaving those to the schema.

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+resource: send a schema and a sink to collect values blindly, with a named list of sink types. It distinguishes itself from the sibling blind_input_preview and from value-returning tools by emphasizing 'you never receive values,' so an agent can tell what this tool is for 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 operational guidance: 'Use blind_input_preview first to validate a complex schema' and notes that non-store sinks require explicit approval on the page. It lacks explicit when-not guidance relative to other capture siblings like secret_request or web_capture, so no full alternatives mapping.

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