Publish the project to pmptwiki.com. Non-interactive — just provide slug and optional metadata. MANDATORY pre-publish checklist: (1) Run pmpt_history — if ANY version lacks a note/summary, you MUST fix it before publishing. (2) For each empty version, run pmpt_diff for that version to understand ...
AI agents use pmpt_publish to create or update resources in Pmpt — usually the action step of a workflow, after the agent has gathered context. Every call changes real data in your Pmpt environment.
pmpt_publish creates new content on pmptwiki.com by publishing a project. While publication is a form of write operation, the severity is high rather than critical because: (1) it publishes to a community platform rather than a production system, (2) the description emphasizes mandatory pre-publish checks that mitigate risks, and (3) published content could potentially be modified or removed, making it reversible.
From the tool's definition Tool description explicitly states 'Publish the project to pmptwiki.com' and references saving/backfilling version history with summaries before publication. The tool creates or modifies publicly visible content on an external community platform.
Documented attack patterns abuse exactly the kind of access pmpt_publish gives an agent:
PolicyLayer is an MCP gateway — it sits between your AI agents and Pmpt, and nothing reaches the server without passing your rules. This is the rule we recommend for pmpt_publish:
{
"version": "1",
"default": "deny",
"tools": {
"pmpt_publish": {
"limits": [
{
"counter": "pmpt_publish_rate",
"window": "minute",
"max": 30,
"scope": "grant"
}
]
}
}
}pmpt_publish stays usable, but capped — an agent stuck in a loop can't make hundreds of changes a minute. Everything else on the server is denied unless you say otherwise.
Free to start. No card required.
Publish the project to pmptwiki.com. Non-interactive — just provide slug and optional metadata. MANDATORY pre-publish checklist: (1) Run pmpt_history — if ANY version lacks a note/summary, you MUST fix it before publishing. (2) For each empty version, run pmpt_diff for that version to understand what changed, then use pmpt_update_doc with a DETAILED progressNote (3-5 sentences explaining what, why, and key decisions) and snapshotVersion. Write like a dev blog — others will read this to learn from your journey. (3) After backfilling all versions, run pmpt_save with a detailed summary. (4) Run pmpt_quality to verify readiness. DO NOT publish with empty or vague single-line versions — they display poorly on the project page. Note: user must have run. It is categorised as a Write tool in the Pmpt MCP Server, which means it can create or modify data. Consider rate limits to prevent runaway writes.
Register the Pmpt MCP server in PolicyLayer and add a rule for pmpt_publish: allow, deny, rate-limit, or require approval. Point your MCP client at the PolicyLayer proxy URL and the rule is enforced on every call, before it reaches Pmpt. Nothing to install.
pmpt_publish is a Write tool with medium risk. Write tools should be rate-limited to prevent accidental bulk modifications.
Yes. Add a rate_limit block to the pmpt_publish rule in your PolicyLayer policy. For example, setting max: 10 and window: 60 limits the tool to 10 calls per minute. Rate limits are tracked per agent session and reset automatically.
Set action: deny in the PolicyLayer policy for pmpt_publish. The AI agent will receive a policy violation error and cannot call the tool. You can also include a reason field to explain why the tool is blocked.
pmpt_publish is provided by the Pmpt MCP server (pmptwiki/pmpt-cli). PolicyLayer sits as a proxy in front of this server to enforce policies before tool calls reach the server.
Start from Pmpt, add the rest of your stack, and see everything your agents can call. Then put policy on all of it.
Free to start. No card required.
14 Pmpt tools catalogued and risk-classified — across an index of 43,000+ MCP servers.