Skip to main content
Glama

Tommos

by ai.tommos
OverviewDiscussionsAdmin

Set where the workspace's meetings come from

set_the_source_of_meetings
Idempotent

Add one source of the workspace's meeting records; a workspace takes them from one, two or all three at once, and adding one never removes another: «granola», read with the workspace's own Granola key; «google-meet», the meetings the workspace's people organize in Google Meet, each through their own Google account, which a person connects once by signing in (refused while nobody has); or «other-tools», the tool the person names (tool), and, when that tool keeps its transcripts in a Google Drive folder, that folder by its link or its Drive id, shared with Tommos's own Google account (when that account cannot open it, the refusal names the address to share it with) and not inside another workspace's Tommos folder — each text file in it is one meeting. Setting a source that stopped working makes it work again; meetings already kept stay, and the source is read at once. For the owner only.

Input Schema

NameRequiredDescriptionDefault
toolNoThe name of the other tool, as the person says it. Only with other-tools.
folderNoThe folder where the other tool keeps its transcripts: its link as Drive gives it, or its Google Drive id. Only with other-tools.
sourceYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changed
    • changedInput schema / properties / folder / description
      Previous value: -"The folder's link as Drive gives it, or its Google Drive id. Only with a-folder-of-files."New value: +"The folder where the other tool keeps its transcripts: its link as Drive gives it, or its Google Drive id. Only with other-tools."
    • changedInput schema / properties / source / enum
      Previous value: -[
-  "granola",
-  "a-folder-of-files"
-]New value: +[
+  "granola",
+  "google-meet",
+  "other-tools"
+]
    • addedInput schema / properties / tool
      Added value: +{
+  "description": "The name of the other tool, as the person says it. Only with other-tools.",
+  "type": "string"
+}
  2. First observed

TDQS

A4.2/5.0
Behavior5/5

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

Beyond the annotations it discloses that adding a source never removes another, that re-setting a stopped source revives it, that meetings already kept stay, that the source is read immediately, and the exact refusal conditions (google-meet refused while nobody has connected; folder refusal names the address to share with). Owner-only authorization and cross-workspace folder exclusion add real operational context.

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?

The core purpose is front-loaded, but the body is one sprawling run-on sentence dense with em-dashes and «» quoting that is hard to parse in a single pass. The content largely earns its place, but the structure undermines readability.

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 3-parameter, no-output-schema mutation tool, the description covers authorization, additive semantics, reactivation, refusal behavior, and per-source preconditions. An agent has everything needed to select a source value and anticipate failure modes.

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 67%, and the description compensates by explaining what each enum value means and how `tool`/`folder` apply only with other-tools, including the folder's form (link or Drive id) and permission constraints. It adds meaning beyond the raw schema descriptions, though it doesn't restate formats exhaustively.

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 opens with a specific verb and resource: 'Add one source of the workspace's meeting records,' and names the three concrete source values. It is unmistakably about meeting-source configuration, though it never explicitly routes against siblings like save_the_granola_key or read_a_meeting.

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?

It gives clear context for each option (granola read with the workspace key; google-meet via each person's account; other-tools with a named tool/folder) and notes 'For the owner only' plus reactivation of a stopped source. However, it never names an alternative tool or an explicit when-not-to-use-this condition.

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

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