Skip to main content
Glama
Cafelatte1

FronyBoard

help

Read the full FronyBoard guide as Markdown to learn what the platform does, which tool to call when, and how a session works before making other calls.

Instructions

Use it for questions about FronyBoard itself — what it is for, which tool to call when, and how a session works with it — and read it once before your first other call in a conversation. Returns the whole guide as Markdown text.

To read or change what is recorded, call the working tools directly: get_status,
create_task, transition_task, list_tasks, search_tasks.

Input Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.41.0

TDQS

A4.3/5.0
Behavior4/5

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

No annotations are provided, so the description carries the full burden. It discloses the return format ('the whole guide as Markdown text') and calls all other tools 'working tools' for data access, which implies that this tool only reads information. It doesn't explicitly say there are no side effects or that the output is large, which would help an agent decide whether to read the full output.

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 main purpose is stated first, followed by the return format, and then the guidance on alternatives, which is separated for clarity. Every sentence adds useful information, and no sentence is wasted.

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?

No output schema exists, so the description must explain what is returned, and it does so by saying the return value is the whole guide as Markdown text. Combined with the usage guidance and the explicit routing to sibling tools, the description is nearly complete; only the size or structure of the guide is left unspecified.

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?

The tool has no parameters, so there is no risk of misuse. The 100% schema coverage is trivially satisfied by an empty object, so there are no parameter semantics to add.

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?

States a specific verb and resource: it answers questions about FronyBoard itself (what it is for, which tool to call when, how sessions work). This is clearly different from the working tools listed. It falls short of 5 only because 'help' is still a broad label and the description doesn't quite pin down the scope of the guide.

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

Usage Guidelines5/5

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

Gives an explicit usage rule ('read it once before your first other call in a conversation') and explicitly states a use case to avoid: for reading or changing recorded data, call get_status, create_task, transition_task, list_tasks, or search_tasks instead. Both when to use it and when to use alternatives are stated outright.

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