Skip to main content
Glama

Monday

by io.github.pipeworx-io

Remember

remember
Idempotent

Save data the agent will need to reuse later — across this conversation or across sessions. Use when you discover something worth carrying forward (a resolved ticker, a target address, a user preference, a research subject) so you don't have to look it up again. Stored as a key-value pair scoped by your identifier. Authenticated users get persistent memory; anonymous sessions retain memory for 24 hours. Pair with recall to retrieve later, forget to delete.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
keyYesMemory key (e.g., "subject_property", "target_ticker", "user_preference")
valueYesValue to store (any text — findings, addresses, preferences, notes)

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. First observed

TDQS

A4.3/5.0
Behavior4/5

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

Annotations already indicate write intent (readOnlyHint false) and idempotency. The description adds valuable context on storage scope (key-value scoped by identifier) and retention policies (persistent for authenticated users, 24 hours for anonymous). No contradiction with annotations.

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?

Three sentences front-loaded with the core action, followed by usage and storage details. No wasted words; each sentence earns its place.

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 simple 2-parameter tool with no output schema, the description covers purpose, usage, persistence, and companion tools. It provides enough context for an agent to decide when and how to use it.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema covers 100% of parameters with descriptive examples. The description adds minimal parameter-specific meaning beyond 'key-value pair', so the schema already does the heavy lifting.

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 clearly states it saves data for later reuse, with specific examples of what to store (ticker, address, preference). It distinguishes from siblings recall and forget by naming them as companions, not duplicating their function.

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?

Provides explicit 'Use when' guidance with concrete scenarios (resolved ticker, target address, user preference). It also points to complementary tools (recall, forget). Lacks explicit 'when not to use' exclusions, but the guidance is strong.

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

All Monday toolsInspect
Try in Browser
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A3.8/5.0
Disambiguation3/5

Several tools occupy nearly identical roles: ask_pipeworx_beta is explicitly a behavioral duplicate of ask_pipeworx, and ai_visibility_check is wrapped by scan_competitor_ai_presence; deep_research and ask_pipeworx also overlap at different granularity. The extremely detailed descriptions help separate most tools, but an agent can still easily pick the wrong query or research variant.

Naming Consistency3/5

Most tools use snake_case, but the naming pattern mixes verb phrases (list_boards, search_items), noun phrases (entity_profile, polymarket_arbitrage), and branded roots (ask_pipeworx, pipeworx_trending). The Monday tools consistently use monday_ prefixed verbs, but there is no single predictable convention across the whole set.

Tool Count2/5

With 36 tools, this is well into the over-packed range, and many entries are meta-tools (suggest_questions, discover_tools, pipeworx_trending, pipeworx_feedback) that inflate the surface. The server bundles a massive Pipeworx data ecosystem with only five Monday tools, making it feel too heavy for one MCP connection.

Completeness3/5

The data side is extensive: querying, grounded verification, research, comparisons, subscriptions, memory, prediction markets, and feedback are all covered. However, the Monday.com side is only a partial lifecycle—create, get, list, and search exist, but there is no update or delete item, and no board creation or editing, which creates dead ends in basic project-management workflows.

Resources