tabpilot-mcp

Overview Schema Source Related Servers Discussions Admin

fill_matrix

Answer matrix/grid questions row by row with controlled delays to prevent React batching issues, then verify the completed result. Select column, rows, and skip already answered cells.

Instructions

Answer a matrix/grid question one row at a time, then verify the result.

Rows are clicked in separate JavaScript tasks with a delay between them. Clicking them in a loop instead makes React batch the updates and commit only the last row, leaving the rest blank and the page stuck failing validation.

Args: tab_id: Exact tab id. url_pattern: Regex matched against tab URLs. selector: Override the matrix container selector. question_index: Which matrix question, as numbered by scan_matrix. column_index: Which answer column to pick. Negative counts from the right, so -1 is the last column. rows: Specific row indices. Defaults to whichever rows need answering. only_unanswered: Skip rows that already have an answer. delay_ms: Delay between rows. Raise it to 150-250 if rows stay blank.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`rows`	No
`tab_id`	No
`delay_ms`	No
`selector`	No
`url_pattern`	No
`column_index`	No
`question_index`	No
`only_unanswered`	No

Output Schema

TableJSON Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Sep 17, 2026

TDQS

A4.8/5.0

Behavior5/5

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It explains the critical implementation detail that rows must be clicked in separate tasks with a delay, warns of the React batching failure mode if looped, and advises adjusting delay_ms to 150-250 if rows stay blank. It also mentions verification after filling, which is valuable beyond the schema.

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 front-loads the purpose in the first sentence, then gives a concise but essential behavioral warning, followed by a compact Args list. Every sentence adds operational value and there is no redundant repetition of schema information.

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?

For a complex 8-parameter browser automation tool with no schema descriptions and no annotations, the description covers all parameters, the key failure mode, and the verification step. An output schema exists, so not describing return values is acceptable; the description is sufficiently complete for correct invocation.

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

Parameters5/5

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

Schema description coverage is 0%, and the description compensates by documenting all 8 parameters with meaningful semantics. It explains defaults (rows defaults to needing answering, only_unanswered defaults true), negative column index behavior, and the relationship between question_index and scan_matrix, plus concrete delay guidance.

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 clear specific action: 'Answer a matrix/grid question one row at a time, then verify the result.' It names the resource (matrix/grid) and method (answer one row at a time), and distinguishes it from generic fill/click tools by its row-by-row verification behavior.

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 provides clear context: the tool addresses matrix/grid questions, rows are clicked in separate JavaScript tasks with a delay, and question_index comes from scan_matrix. It warns against looping due to React batching, giving concrete conditions when to raise delay. However, it does not explicitly name alternative tools or state when not to use this tool, so it falls short of a 5.

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

Deploy Server