chromaphore-mcp

Official

Overview Schema Source Related Servers Discussions Admin

Fill a date or time field

fill_date

Fills date, time, datetime-local, month, or week inputs part by part as a person types them, using the field’s value-attribute format.

Instructions

Fills an input of type date, time, datetime-local, month or week part by part, as typed by a person. value as the field's value attribute takes it: 2024-05-03, 14:30, 2024-05-03T14:30, 2024-05, 2024-W18.

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": {
      "id": "<id>",
      "value": "<value>"
    },
    "name": "fill_date"
  }
}

Input Schema

Name	Required	Description	Default
`id`	Yes	An element id from a listing, such as a12.
`value`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Nov 10, 2026

TDQS

A4.2/5.0

Behavior3/5

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

With no annotations, the description must carry the behavioral burden. It usefully discloses that values are entered part by part as a person would type them, implying realistic input events, but it does not cover failure behavior, validation, focus handling, or what the tool returns.

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 two tightly written sentences, front-loading the purpose and then the value format. Every phrase contributes either scope or syntax guidance, and the examples are compact.

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 two-parameter browser-fill action with no output schema, the description provides enough context to call it correctly for the supported input types and value formats. It does not address error or edge-case behavior, which is a minor gap for this tool's complexity.

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 only 50% because the value parameter has no schema description. The description compensates by explaining that value follows the field's value attribute and giving concrete examples for each supported input type, though id semantics are left 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?

The description uses a specific verb and resource: it fills inputs of type date, time, datetime-local, month, or week. It distinguishes the tool from generic typing by naming the exact HTML input types and the part-by-part human-style entry 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?

The description clearly establishes the context of use by enumerating the input types this tool applies to. It does not explicitly name alternatives such as type or state when not to use this tool, but the applicable context is unambiguous.

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

Deploy Server