Skip to main content
Glama
piers-fawkes

Fodda Context Layer

by piers-fawkes
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

draft_linkedin_post

Read-only

Draft a LinkedIn post on any topic using expert knowledge graphs, returning verifiable evidence and sources so you can write credible social content.

Instructions

Draft a LinkedIn post about any topic, grounded in Fodda's expert knowledge graphs. Use when the user says "draft a LinkedIn post about…", "write a post on…", "turn this into a LinkedIn post", or wants social content backed by receipts. Returns a curated EVIDENCE PACK (claims with named companies, typed sources, and real URLs — never constructed) plus a strict composition contract; YOU write the post from it. Every claim is verifiable, thin coverage is flagged honestly, and dropped themes are logged with reasons. Bills as one content call; identical re-requests within 24h serve from cache free. (Trend evidence extraction + tone/formatting prompt execution + draft compilation.)

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
angleNoOptional thesis, or a post being responded to
brandNoSet ONLY when the topic IS a named brand/company (e.g. 'Nike'). Unlocks the earnings truth layer: analyst concerns, CEO quotes, and market-validated trends as verbal-attribution evidence.
topicYesThe topic to post about (e.g., 'agentic commerce', 'retail media networks')
voiceNoBridge-line voice: 'fodda_first_party' ("We found these using Fodda…", default) or 'practitioner' ("I pulled these from Fodda…") for users posting about their own industry.
userIdNoOptional user identifier for usage tracking.
sub_themesNo2–4 SPECIFIC sub-themes decomposing the topic (e.g. for 'agentic commerce': ['AI shopping agents checkout', 'retailer agent APIs', 'agent-to-agent payments']). Specific grounded queries consistently beat one broad query — supply these for best results.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv1.3.3

TDQS

A4.4/5.0
Behavior5/5

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

Beyond the annotations (which only cover safety/idempotency), it discloses the return contract (curated EVIDENCE PACK with typed sources and never-constructed URLs), honesty behavior (thin coverage flagged, dropped themes logged), and billing semantics (one content call; identical re-requests within 24h served from cache free). This is rich operational context an agent cannot get from annotations.

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 and sentences are dense with useful detail (triggers, return format, billing). It is somewhat long and packs multiple concerns (caching, billing, sub-operations parenthetical) that could be trimmed, but nothing is clearly wasteful.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema, the description carries the return-format burden and does so fully: evidence pack structure, composition contract, coverage honesty, caching and billing. An agent knows what it gets back and how it is charged before calling.

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 parameter descriptions (brand's earnings truth layer, voice enum, SPECIFIC sub_themes guidance) are already detailed. The description adds no per-parameter meaning beyond the schema, 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 names a specific verb (Draft) and resource (LinkedIn post) and scopes it to 'any topic, grounded in Fodda's expert knowledge graphs'. It also clarifies the division of labor ('YOU write the post' from the returned evidence pack), which distinguishes it from a plain generation tool.

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 concrete trigger phrases ('draft a LinkedIn post about…', 'write a post on…', 'turn this into a LinkedIn post') and states the context (social content backed by receipts). It does not, however, name the sibling draft_linkedin_article or state when to prefer one over the other, so it stops short of fully explicit alternative routing.

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

Deploy Server

Other Tools