Skip to main content
Glama
Sign In
Colibri

Colibri

by t4zxxx1
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Hybrid

Compito guidato

browse_task

Fill, verify, and submit web forms from structured parameters, then extract or read page results. Uncertain values return as questions with probabilities.

Instructions

Form task: local engine maps params to fields (synonyms, typos, languages), fills selects, autocompletes, dates (split day/month/year[/h/min] fields too: one "DD/MM/YYYY [HH:MM]") and checkboxes, verifies, then submit/expect/extract/read. Uncertain params come back as questions with probabilities.

Input Schema

NameRequiredDescriptionDefault
urlNo
readNo
viewNo
beforeNobrowse_do steps run first
expectNotext expected after submit
paramsNofield label (or ref) -> value | {value, about, secret}
submitNobutton name(s) to press last; true = form submit
answersNoparam -> ref (remembered per site) or suggestion text
confirmNoonly after the user OK: allows !c actions
extractNoname -> text|number|money|date|url|table
confidenceNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changedv0.5.8
    • changedInput schema / properties / params / description
      Previous value: -"field label as the user would say it (or ref) -> value | {value, about, secret}"New value: +"field label (or ref) -> value | {value, about, secret}"
    • changedInput schema / properties / read / enum
      Previous value: -[
-  "text",
-  "table"
-]New value: +[
+  "text",
+  "table",
+  "cards"
+]
    • changedInput schema / properties / submit / description
      Previous value: -"button name(s) to press at the end; true = form submit"New value: +"button name(s) to press last; true = form submit"
  2. First observedv0.4.0

TDQS

B3.4/5.0
Behavior3/5

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

With no annotations, the description carries full burden. It discloses genuinely useful behavior: fuzzy field matching (synonyms, typos, languages), date normalization into a single DD/MM/YYYY [HH:MM] value, verification before submit, and a probabilistic question-return mode for uncertain params. It does not disclose failure semantics, what happens to partially-filled forms, whether submission is reversible, or auth requirements.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

It is dense with no filler, but it is a single run-on sentence that mixes mechanism, field types, and workflow, with the critical ask/answer behavior buried at the end. Front-loading is weak and the parenthetical date clause interrupts the flow.

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

Completeness3/5

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

For an 11-parameter tool with nested objects, no annotations, and no output schema, the description covers the core mechanics but not the workflow shape (when to call it, what a question-response cycle looks like before re-invoking) or failure behavior. Adequate to attempt a call, insufficient to call it confidently on a complex form.

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 64%, so the baseline is 3, but the description adds real meaning beyond the schema: the format expected for date-shaped params ('one DD/MM/YYYY [HH:MM]'), how 'answers' pairs with returned questions, and the gating condition for 'confirm'. It still leaves url, view, before, and confidence unexplained.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description names a concrete capability: driving a form task end-to-end (map params to fields, fill selects/autocompletes/dates/checkboxes, verify, then submit/expect/extract/read). That is far more than a restated title such as 'guided task'. It stops short of stating how this differs from the close sibling browse_do, which it only mentions indirectly as a step-runner in the 'before' param.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Usage is implied rather than stated: the sentence about uncertain params returning as questions reveals a two-turn ask/answer workflow (with 'answers' resolving it), and 'confirm: only after the user OK' hints at the safety gate. There is no explicit when-to-use vs browse_do/browse_open/browse_read, nor any exclusion or prerequisite.

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