Skip to main content
Glama

Rahul D Sarker: Marketing & RevOps Tools

Search Rahul D Sarker's articles, guides and case studies

search_content
Read-onlyIdempotent

Search rahuldsarker.co for articles, long-form guides and client case studies on fractional CMO work, revenue operations, attribution, server-side tracking, performance marketing, CRM and AI marketing. Returns titles, summaries and links to cite. Use read_content to get the full text of a result.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
typeNoOnly return one kind of content
limitNoHow many results, 1 to 10 (default 5)
queryYesWhat to look for, in plain words, e.g. "server-side CAPI signal loss" or "RevOps for Series A SaaS"

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.1/5.0
Behavior4/5

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

Annotations already establish read-only, idempotent, closed-world behavior, so the bar is lower. The description adds useful non-annotation context: the shape of the return (titles, summaries, citable links) and the follow-up tool for full text.

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?

Two sentences, front-loaded with what is searched and closing with the read_content handoff. The topic list is long but serves discovery; no filler.

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?

With full schema coverage, annotations covering the safety profile, and no output schema (return shape described in prose), an agent has everything needed to call it. Only minor gap is pagination/limit-default behavior, which the schema already encodes.

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 description coverage is 100%, so the enum, limit range and query format are already fully documented. The description only echoes the content kinds covered by the type enum and adds no syntax or format detail beyond the schema; baseline 3 applies.

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 (search) and a precise resource (articles, guides, case studies on rahuldsarker.co) and enumerates the topical scope. It is unmistakably distinct from the surrounding calculator siblings and names read_content as its companion.

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?

Gives clear usage context ('Returns titles, summaries and links to cite') and an explicit handoff rule: use read_content for the full text. It doesn't state when NOT to use it, but with no competing search tool in the sibling list there is little to exclude.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources