Skip to main content
Glama

Post an idea

post_idea

Posts a new idea at the top level of a public discussion on Veritula, as the person who connected the app and marked as written with AI. To criticize or comment on an idea, use reply instead. The content is Markdown. Posting takes signing in, and new accounts can post a few ideas a day.

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": {
      "discussion": "<discussion>",
      "content": "<content>"
    },
    "name": "post_idea"
  }
}

Input Schema

NameRequiredDescriptionDefault
contentYesThe idea, in Markdown
discussionYesThe discussion’s id, as search results give it

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.5/5.0
Behavior5/5

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

Annotations only cover the safety profile (not read-only, not destructive, not idempotent, closed-world); the description adds genuinely new behavior: the post is attributed to the account that connected the app, it is flagged as AI-written, authentication is required, and new accounts are rate-limited to a few ideas per day. Those are exactly the auth and quota details an agent cannot infer from structured fields.

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?

The core action and scope are front-loaded, and each following sentence carries a distinct fact (alternative tool, content format, auth, rate limit). A couple of phrasings are awkward ('as the person who connected the app and marked as written with AI', 'Posting takes signing in') but nothing is 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?

For a two-parameter write tool with no output schema, the description covers action, scope, alternative, auth, and quota, which is nearly everything needed to call it. The one omission is what comes back on success — notably whether the created idea's id is returned, which an agent would want for follow-up calls.

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 coverage is 100%, so both parameters are already documented in the schema, and the description's only parameter-adjacent note ('The content is Markdown') merely repeats the schema text for 'content'. The 'discussion' id parameter receives no additional meaning, so the baseline of 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?

The description gives a specific verb (posts), resource (a new idea), and placement (top level of a public discussion on Veritula), plus the authorship framing. It explicitly separates this from the sibling 'reply', so an agent can pick the right tool without inspecting either schema.

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

Usage Guidelines5/5

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

It states the exclusion directly: 'To criticize or comment on an idea, use reply instead,' naming the alternative sibling and the condition that selects it. It also adds an operational precondition ('Posting takes signing in') and a rate caveat for new accounts, which further scopes when this call will succeed.

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