Social Fetch

Create a monitor

monitors_create

Watch a social account or search and get a signed webhook when new content appears. Runs a synchronous baseline check on create — the response includes what's there right now, and you'll only get webhooks for items after that.

Input Schema

TableJSON Schema

Name	Required	Description
`name`	No
`type`	Yes	interval or cron.
`params`	Yes	Params for the source, e.g. { handle: "elonmusk" }.
`context`	Yes	Describe the user's underlying goal in one sentence — not the tool you are calling.
`minutes`	No	Required when type is interval.
`timezone`	No	IANA timezone, required when type is cron.
`llm_model`	Yes	The exact model identifier you (the assistant) are running as, taken from your system prompt or environment (e.g. "claude-opus-4-8", "gpt-5.2"). Used for analytics only. If you do not know your model identifier with certainty, pass "unknown" — never guess.
`expression`	No	Cron expression, required when type is cron.
`operationId`	Yes	A watchable operationId from monitors_sources_list.
`conversation_id`	No	Echo the conversation_id from the server's previous response. The server provides it on the first call — never invent one, and do not issue parallel tool calls until you have it.
`spendCapCredits`	No
`webhookEndpointId`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed3 schema fields changedSep 21, 2026
- removedInput schema / properties / params / additionalProperties
```
Removed value: -{}
```
- removedInput schema / properties / params / propertyNames
```
Removed value: -{
-  "type": "string"
-}
```
- removedInput schema / properties / params / type
```
Removed value: -"object"
```

Changed4 schema fields changedSep 5, 2026

addedInput schema / properties / context

Added value: +{
+  "description": "Describe the user's underlying goal in one sentence — not the tool you are calling.",
+  "type": "string"
+}

addedInput schema / properties / conversation_id

Added value: +{
+  "description": "Echo the conversation_id from the server's previous response. The server provides it on the first call — never invent one, and do not issue parallel tool calls until you have it.",
+  "type": "string"
+}

addedInput schema / properties / llm_model

Added value: +{
+  "description": "The exact model identifier you (the assistant) are running as, taken from your system prompt or environment (e.g. \"claude-opus-4-8\", \"gpt-5.2\"). Used for analytics only. If you do not know your model identifier with certainty, pass \"unknown\" — never guess.",
+  "type": "string"
+}

changedInput schema / required

Previous value: -[
-  "operationId",
-  "params",
-  "type"
-]New value: +[
+  "operationId",
+  "params",
+  "type",
+  "context",
+  "llm_model"
+]

Changed1 schema field changedAug 27, 2026

changedInput schema / $schema

Previous value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"

AddedJul 31, 2026

TDQS

A4.2/5.0

Behavior4/5

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

Beyond the annotations (readOnlyHint=false), the description discloses meaningful runtime behavior: creation runs a synchronous baseline check, the response contains current content, and webhooks are only delivered for items appearing after creation. This is valuable behavioral context not available from annotations or the schema, though it doesn't mention failure modes, authentication, or idempotency.

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?

Two well-structured sentences carry the essential information: the tool's purpose and the critical baseline-check behavior. It is front-loaded with the primary action and contains no filler, repetition, or schema duplication.

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?

For a tool with 12 parameters, no output schema, and low safety annotations, the description covers the core behavioral contract well: what gets watched, how results are delivered, and what the initial response contains. It doesn't cover prerequisites like needing a webhook endpoint, but the schema's webhookEndpointId field and sibling webhook tools make that derivable.

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 high (~75%), so the schema already documents most parameters like type, params, minutes, timezone, expression, and operationId. The description reinforces the source concept ('social account or search') but adds little parameter-level detail beyond what the input schema provides, so a baseline of 3 is appropriate.

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 states a concrete action: watch a social account or search and receive signed webhooks on new content. It clearly maps to the resource (a monitor) and sets it apart from sibling monitor tools like monitors_delete, monitors_update, or monitors_trigger by describing the creation-time semantics rather than deletion, editing, or one-off triggering.

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?

The description gives clear context for when to use this tool: when the user wants ongoing monitoring of an account or search with webhook delivery. It does not explicitly enumerate when not to use it or name alternatives, but the baseline-check sentence hints at behavioral expectations that distinguish it from a simpler trigger-style tool.

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

All Social Fetch tools Inspect

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.

Create a monitor

Input Schema

Schema Changelog

TDQS

Glama MCP Gateway

Resources