Skip to main content
Glama
Sign In

findtime.io MCP Server

by io.github.hkchao
OverviewDiscussionsAdmin

Report a wrong answer

send_feedback

Sends findtime.io a report that one of its tool answers was wrong, incomplete, or unhelpful. Required: tool, query, and whatWasWrong. Optional: expectedAnswer. The query is used only to classify the report and is then discarded; findtime.io keeps the tool name, an error class, flags, and counts, not the query, the expected answer, or any other free text. The fields are not meant for names, emails, phone numbers, IP addresses, or user ids.

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": {
      "tool": "<tool>",
      "query": "<query>",
      "whatWasWrong": "<whatWasWrong>"
    },
    "name": "send_feedback"
  }
}

Input Schema

NameRequiredDescriptionDefault
toolYesMCP tool that produced the unhelpful result, such as answer_time_question, convert_time, or get_current_time.
queryYesOriginal time query or lookup text without names, emails, or other personal data.
_endUserIdNoOptional opaque per-call end-user attribution token populated by the MCP host, not the LLM. Accepts a non-PII hash or token, excluding raw email addresses, names, or platform user IDs.
whatWasWrongYesShort description of the mistake or why the answer was unhelpful.
expectedAnswerNoOptional correct time, timezone, or location the tool should have returned.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.5/5.0
Behavior5/5

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

Goes well beyond the annotations by disclosing data-handling behavior an agent could not otherwise infer: the query is used only for classification and discarded, and only tool name, error class, flags, and counts are retained. It also flags the PII constraint on inputs. Annotations (readOnlyHint=false, openWorldHint=false) are consistent with "sends a report" and add the safety frame, so the description is additive rather than redundant.

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 sentences, purpose front-loaded and nothing wasted. The retention and PII sentences are dense but each earns its place; the PII/privacy material is somewhat interleaved with the field requirements rather than cleanly separated.

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 5-parameter write-side tool with no output schema, the description covers intent, required fields, and privacy behavior well. It does not say what the call returns on success or whether repeated reports are deduplicated, which are minor remaining gaps given the strong data-handling disclosure.

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 100%, so the baseline is 3, but the description adds real meaning: it separates required (tool, query, whatWasWrong) from optional (expectedAnswer) and clarifies that query exists solely for classification, which shapes how the agent should populate it. It does not address the _endUserId host-populated parameter, leaving one gap.

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?

Specific verb and resource ("Sends findtime.io a report that one of its tool answers was wrong, incomplete, or unhelpful") with a precise trigger condition. It is unmistakably distinct from every sibling, all of which are time/booking operations, and an agent can select it without further inspection.

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?

Clear about when to use it (wrong, incomplete, or unhelpful tool answers) and implicitly scopes out other purposes with "The fields are not meant for names, emails, phone numbers, IP addresses, or user ids." It does not name a competing alternative or state an explicit when-not-to-file condition (e.g. duplicates, transient errors), 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.

All findtime.io MCP Server toolsInspect
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources