Skip to main content
Glama

The Profound Agency

by io.github.Jfromtheroc
OverviewDiscussionsAdmin

Send the client's content for their article

submit_content
Destructive

What one publication's article should be built from, the same as the form on the client's order page. Each publication on an order needs its own. Needs at least who they are and what the article should say, or a draft of their own. Only while that publication is waiting for content; sending again replaces the earlier version. We then write an outline for the client to approve. Confirm the content with the client before sending.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
nameNoHow the article should name them: a person, a business or a pen name.
aboutNoWho the client is, in a few sentences.
angleNoTheir news, launch, milestone or point of view.
draftNoA draft of their own, if they have one. Client-written articles are more likely to be turned down by editors, so expect edits.
factsNoProof points: numbers, results, credentials, awards, a quote from them in their exact words.
linksNoUp to three links; most publications allow two or three.
notesNoAnything else.
photoNoA link to a photo.
orderLinkYesThe client's private order link (https://theprofound.agency/order/<id>/#t=…), or just the token after #t=. It is the "Open your order page" button in the order confirmation email sent when the order is paid.
publicationNoWhich publication on the order: its name or publicationId from get_client_order. Needed when the order has more than one; each publication has its own content, outline and draft.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • addedInput schema / properties / publication
      Added value: +{
+  "description": "Which publication on the order: its name or publicationId from get_client_order. Needed when the order has more than one; each publication has its own content, outline and draft.",
+  "type": [
+    "string",
+    "number"
+  ]
+}
  2. Changed1 schema field changed
    • changedInput schema / properties / orderLink / description
      Previous value: -"The client's private order link from our email (https://theprofound.agency/order/<id>/#t=…), or just the token after #t=."New value: +"The client's private order link (https://theprofound.agency/order/<id>/#t=…), or just the token after #t=. It is the \"Open your order page\" button in the order confirmation email sent when the order is paid."
  3. First observed

TDQS

A4/5.0
Behavior4/5

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

The annotations already declare destructiveHint=true and idempotentHint=false. The description adds useful behavioral context beyond that: re-sending replaces the earlier version, the team writes an outline afterward for approval, and the client should confirm the content first. It does not describe failure modes or permissions, but the replacement and workflow details are valuable.

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 description is six sentences and front-loads the core definition before moving to requirements, timing, and workflow. It is not bloated, though it could be slightly tighter by consolidating the content requirements into fewer clauses.

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 10-parameter mutation tool with no output schema, the description covers the key context: content inputs, publication scope, submission timing, replacement behavior, and downstream outline approval. It is complete enough to call correctly, though it does not cover errors or return behavior.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the baseline is 3. The description adds meaning by stating that at least identity and article substance, or a client draft, are needed, and by clarifying that the publication parameter is required when an order has multiple publications.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description and title together indicate submitting the content a publication's article will be built from, and it clarifies that each publication on an order needs its own content. It does not explicitly distinguish this tool from the sibling submit_article_draft, but the core purpose is clear.

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 states a clear condition: only while the publication is waiting for content, and sending again replaces the earlier version. It also advises confirming with the client before sending. It stops short of naming alternatives such as submit_article_draft, so the agent gets context but not sibling routing.

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

All The Profound Agency 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