freedom-mcp

Complete my activity

complete_my_activity

Destructive

Stamp one due job as done AFTER you deposit the work, and prove it. Use when get_my_role listed this activity in due_now and you have already deposited the deliverable. Pass deposit = { kind, ref } naming what you made this turn — a knowledge slug (save_knowledge), a card id (send_to_user), a content id (submit_content_to_pipeline), a lead id (add_lead) or an evidence id (add_customer_evidence). The stamp checks the deposit exists in this company, was made since the job last ran, and has not stamped another job (one deposit clears one job); without a valid deposit the answer is not-done and due_now keeps the job. The only job that needs no deposit is the one-time "Preflight check". Pass the exact activity name from the brief. A role key stamps its own role; with an operator key, pass agent_id.

Routing: After depositing a due job → complete_my_activity (not remove_agent_activity)

[write-tier — first use may require a manager's approval; a from-now-on approval makes future calls seamless, a just-once approval re-asks next time. Call it on the first clear ask; the card is the yes — do not re-ask in chat.]

Input Schema

TableJSON Schema

Name	Required	Description
`note`	No	Optional one-line what you deposited (stored on the run, not a second product).
`deposit`	No	The proof of work: what you made this turn. Required for every job except the one-time "Preflight check".
`agent_id`	No	The role this job belongs to. Omit it when you are calling with that role's own key.
`companyId`	Yes	FreedomOS company id to act within (you must be a member). Required for company-scoped tools.
`activity_name`	Yes	Exact name from get_my_role due_now (case-insensitive).

Schema Changelog

Changes observed during successful MCP inspections.

AddedSep 23, 2026

TDQS

A4.9/5.0

Behavior5/5

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

The description explains the validation behavior in detail: the deposit must exist in the company, must have been made since the job last ran, and must not have already stamped another job. It also discloses the not-done outcome, the Preflight exception, and the write-tier approval behavior beyond what annotations convey.

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 long but each sentence carries operational value. It is organized with clear routing and approval guidance, though it could be tightened; the write-tier approval paragraph is dense and mixes multiple instructions together.

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?

Given the nested deposit object, no output schema, and complex validation semantics, the description covers everything an agent needs: when to call, what to pass, how the stamp is verified, the exception for Preflight, key behavior, and routing to an alternative. Nothing critical is missing.

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

Parameters5/5

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

Although schema coverage is 100%, the description adds substantial meaning: it maps each deposit kind to the tool that produces it, clarifies that the activity_name must match the brief exactly, explains when agent_id is omitted, and defines the purpose of note. This goes well beyond the schema field descriptions.

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 opens with a specific verb and resource: 'Stamp one due job as done AFTER you deposit the work, and prove it.' It clearly identifies this as the completion action for due activities from get_my_role, and the Routing note differentiates it from remove_agent_activity.

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 exactly when to use the tool: when get_my_role listed the activity in due_now and the deliverable has already been deposited. It also provides an explicit routing rule, 'After depositing a due job → complete_my_activity (not remove_agent_activity)', and specifies when agent_id is required.

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

All freedom-mcp tools Inspect

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

Need Help?