Skip to main content
Glama
Sign In

ContentIn for Agents

by io.contentin
OverviewDiscussionsAdmin

Capture substance to the content bank

capture_substance

Save a piece of the user's first-party substance — a story, an opinion, a data point, or a framework — into their ContentIn content bank, filed under one of their content pillars. This is the highest-leverage thing you can do for them: everything ContentIn writes later is grounded in this bank, so capturing what they tell you in passing compounds. Use it whenever the user shares a real experience, a genuine opinion, a concrete number or result, or a process they use. Pass the pillar by NAME if you don't know its id. Duplicates are detected and rejected automatically, so capturing something twice is harmless.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "content_pillar": "<content_pillar>",
      "substance_type": "<substance_type>",
      "content": "<content>"
    },
    "name": "capture_substance"
  }
}

Input Schema

NameRequiredDescriptionDefault
contentYesThe substance itself, cleaned into one clear self-contained piece — but in the user's own words and with their own specifics intact. Do not generalise the detail out of it.
content_pillarYesThe content pillar's name or id. The name is fine — it is matched either way.
substance_typeYesstories = personal or client anecdotes; opinions = beliefs and contrarian takes; data_points = numbers, metrics, results; frameworks = step-by-step processes and mental models.

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 declare this is a write (readOnlyHint=false) that is non-destructive and non-open-world, so the safety profile is already covered. The description adds genuinely new behavior: duplicates are detected and rejected automatically, and the bank grounds all later writing. The claim that capturing twice is 'harmless' sits in mild tension with idempotentHint=false, though it describes a duplicate check rather than true idempotency, so it isn't a contradiction.

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?

Purpose is front-loaded, followed by usage triggers, then the pillar hint and the duplicate note. The 'highest-leverage thing you can do' sentence is promotional, but it earns some place by motivating proactive capture; overall the text is tight for the amount of guidance it delivers.

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 three-parameter write tool with no output schema, the description covers what to capture, where it is filed, and how duplicates behave. It never says what the call returns (e.g. a created item id), which would help an agent confirm success, but nothing essential for correct invocation is missing.

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% and the enum for substance_type is fully documented in the schema itself, so baseline is 3. The description's only added parameter guidance is that the pillar can be passed by name or id, which duplicates what the content_pillar schema field already says.

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 specific verb and resource — saving first-party substance (story, opinion, data point, framework) into the user's ContentIn content bank, filed under a content pillar. That framing distinguishes it cleanly from siblings like generate_ideas or write_post_in_my_voice, which produce rather than store content.

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 an explicit trigger list: use it whenever the user shares a real experience, a genuine opinion, a concrete number or result, or a process. It also covers the duplicate case. What's missing is any when-not guidance or a named alternative for adjacent needs, but the positive criteria are unusually concrete.

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

All ContentIn for Agents 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