Skip to main content
Glama

The Profound Agency

by io.github.Jfromtheroc
OverviewDiscussionsAdmin

Approve, or ask for changes to, an outline or draft

review_content
Destructive

The client's decision on one publication's latest outline or draft from get_client_order. Approving an outline starts the draft; approving the draft sends it to our editors for a final read, and cannot be undone. Show the client the full text and get their explicit go-ahead first. Changes can be asked for twice per piece; after that our team works with the client directly.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
pieceYes
actionYes
feedbackNoWith action "changes": what to change, in the client's words.
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.2/5.0
Behavior5/5

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

Annotations already flag destructiveHint=true and non-idempotent, but the description adds real substance: approving the draft sends it to editors and cannot be undone, approving the outline starts the draft, and there is a hard limit of two change requests per piece. These are behavioral constraints an agent cannot infer from the annotations alone.

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?

Three sentences, no filler, and the object of the operation is front-loaded. The opening clause ('The client's decision on one publication's latest outline or draft from get_client_order') is slightly dense but earns its place by anchoring the tool to its data source.

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 five-parameter mutation tool with no output schema and only 60% schema description coverage, the description supplies the prerequisites (explicit client consent), irreversibility, and rate limit. It omits any mention of what the call returns or error behavior, but otherwise an agent has enough to invoke it correctly.

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 60%, so the schema documents orderLink, feedback and publication. The description compensates by explaining what the action enum actually triggers depending on piece (approve outline -> draft starts; approve draft -> editors; changes -> limited to two). It adds little about orderLink/feedback formats, but the enum semantics are meaningfully clarified.

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 states a specific operation: recording the client's approval or change request on one publication's outline or draft, and ties it back to the get_client_order resource. It is clearly distinguishable from content-creation siblings like submit_content or submit_article_draft, though it never names those siblings explicitly.

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?

Strong procedural guidance: show the client the full text and get explicit go-ahead first, and changes can only be requested twice per piece before the team takes over. It routes the agent to get_client_order as the source of the content, but does not contrast itself against the other submit_* siblings that might look similar.

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