Skip to main content
Glama

proofite

by com.proofite
OverviewDiscussionsAdmin

Tune one topic

tune_topic

Tune how a single topic — or a COMBINATION of labels — is treated in future briefings: more or less of it, more or less technical, deeper or shorter, more or less often, muted entirely, or followed so every development of that WHOLE THEME gets reported (to follow one specific story, use rate_briefing_entry with "follow" on that entry). topic is one key: a free tag ("intelligenza artificiale") or a typed label (e:tesla, c:auto, f:soldi); topics instead is a list of labels combined with AND ("e:tesla"+"f:soldi" = Tesla only when about money — Tesla alone stays as it is). This is the precise instrument — for a vague comment like "too much crypto lately" use correct_briefing instead.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
topicNoOne key: a topic as it appears in get_information_diet or in a briefing entry (e.g. "intelligenza artificiale", "e:tesla", "c:auto")
actionYesWhat to change about it
topicsNoAlternative to topic: labels to COMBINE with AND (e.g. ["e:tesla","f:soldi"])

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changed
    • changedInput schema / properties / topic / description
      Previous value: -"The topic, as it appears in get_information_diet or in a briefing entry (e.g. \"intelligenza artificiale\")"New value: +"One key: a topic as it appears in get_information_diet or in a briefing entry (e.g. \"intelligenza artificiale\", \"e:tesla\", \"c:auto\")"
    • addedInput schema / properties / topics
      Added value: +{
+  "description": "Alternative to topic: labels to COMBINE with AND (e.g. [\"e:tesla\",\"f:soldi\"])",
+  "items": {
+    "type": "string"
+  },
+  "maxItems": 4,
+  "type": "array"
+}
    • changedInput schema / required
      Previous value: -[
-  "topic",
-  "action"
-]New value: +[
+  "action"
+]
  2. First observed

TDQS

A4.6/5.0
Behavior4/5

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

Annotations already declare the non-read-only, non-idempotent, non-destructive, closed-world safety profile, so the bar is lower. The description adds genuine behavior beyond that: it persists into future briefings, combining labels via AND leaves the standalone label untouched ("Tesla alone stays as it is"), and "follow" tracks every development of the whole theme. It does not describe reversibility of mute/unmute beyond the action names.

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?

Front-loaded with the core action and scope, and every clause carries information (sibling routing, topic vs topics semantics). It is a long, em-dash-heavy paragraph, so it is dense rather than elegant, but it avoids filler.

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 mutation tool with no output schema and only three parameters, the description covers the action semantics, the topic-vs-topics choice, the AND-combination behavior, the persistence into future briefings, and the sibling alternatives. Nothing an agent needs to invoke it correctly is missing.

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 baseline is 3, but the description adds meaning beyond the schema: it clarifies the alternative relationship between `topic` (one key) and `topics` (a list AND-combined, max semantics illustrated with e:tesla+f:soldi), plus given examples of free tags and typed labels. This is useful disambiguation the schema alone leaves implicit.

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?

States a specific verb (tune) and resource (a topic or label combination) and precisely describes the scope of change: frequency, technicality, depth, length, muting, following. It explicitly separates itself from rate_briefing_entry (single story follow) and correct_briefing (vague comment), so an agent can distinguish it from siblings without opening any schema.

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 explicit routing: use this for a precise single-topic or AND-combination change, use rate_briefing_entry with "follow" for one specific story, and correct_briefing for vague comments like "too much crypto lately". Both when-to-use and when-not-to-use are named.

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

All proofite 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