Skip to main content
Glama

Rattlesnakes By Mail: AI Crawler Field Guide

by com.rattlesnakesbymail
OverviewDiscussionsAdmin

Submit A Note

submit_note

Submit a correction or note about a claim, an entity, a question, or a daily snapshot on Rattlesnakes By Mail. Requires a client token issued out of band by the publisher. Every note is stored as pending, and an editor reviews every pending note before publication.

Input Schema

NameRequiredDescriptionDefault
bodyYesThe note text, up to 2000 characters.
tokenYesA client token issued by Rattlesnakes By Mail.
targetNoShorthand for target_type and target_id, for example snapshot:261101 or question:12.
target_idNoThe id or slug of the claim or entity, the id or hash of the question, or the six digit label of the snapshot, the note is about.
target_typeNoThe kind of record the note is about.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed4 schema fields changed
    • addedInput schema / properties / target
      Added value: +{
+  "description": "Shorthand for target_type and target_id, for example snapshot:261101 or question:12.",
+  "type": "string"
+}
    • changedInput schema / properties / target_id / description
      Previous value: -"The id or slug of the claim or entity, or the id or hash of the question, the note is about."New value: +"The id or slug of the claim or entity, the id or hash of the question, or the six digit label of the snapshot, the note is about."
    • changedInput schema / properties / target_type / enum
      Previous value: -[
-  "claim",
-  "entity",
-  "question"
-]New value: +[
+  "claim",
+  "entity",
+  "question",
+  "snapshot"
+]
    • changedInput schema / required
      Previous value: -[
-  "target_type",
-  "target_id",
-  "body",
-  "token"
-]New value: +[
+  "body",
+  "token"
+]
  2. First observed

TDQS

A3.8/5.0
Behavior4/5

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

Annotations already declare a non-destructive, non-idempotent, closed-world write operation. The description adds valuable context: it requires an out-of-band client token and notes are stored as pending with editor review before publication. It doesn't cover rate limits or error handling, so not a 5.

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, each front-loaded and purposeful: purpose, authentication, and review workflow. No waste or repetition.

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 no output schema and annotations covering safety, the description includes purpose, auth, and outcome (pending/reviewed). It omits what the response returns (e.g., note ID) or error conditions, but is otherwise adequate for a submission tool.

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 schema fully documents all five parameters. The description reinforces the token requirement and lists target types, but adds no syntax or format details beyond what the schema provides.

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 ('Submit') and resource ('correction or note') with explicit target types (claim, entity, question, snapshot). This clearly distinguishes it from sibling tools like ask (asking a question) and get_snapshot (retrieval).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies when to use it (submitting corrections/notes about specific targets) but provides no explicit guidance on when to choose it over alternatives or when not to use it. The only prerequisite mentioned (client token) is not usage guidance.

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

All Rattlesnakes By Mail: AI Crawler Field Guide toolsInspect
Try in Browser
Shareable, User-Owned Context BackendPeople, applications, and agents read, write, and coordinate together in one context lake. Reach it over MCP, a CLI, a Python SDK, or REST.fulcradynamics.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources