org_can_deploy
Whether an account (you when left out) may deploy a cell of the org, and why.
Input Schema
| Name | Required | Description | Default |
|---|---|---|---|
| org | Yes | ||
| acct | No | ||
| cell | Yes |
Whether an account (you when left out) may deploy a cell of the org, and why.
| Name | Required | Description | Default |
|---|---|---|---|
| org | Yes | ||
| acct | No | ||
| cell | Yes |
Changes observed during successful MCP inspections.
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds that the answer comes with a reason ('and why'), which is useful beyond the annotations. However, the annotations declare readOnlyHint=false and openWorldHint=true for what reads as a pure query, and the description neither clarifies why the call is non-read-only nor mentions auth requirements or external lookups. No outright contradiction, but a notable gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single front-loaded sentence with no filler; the optional-parameter default is folded into a compact parenthetical. Slightly cryptic phrasing ('you when left out'), but nothing is wasted.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With three parameters, no output schema, and 0% schema description coverage, the description should explain what the result looks like (boolean plus reason text?) and what a cell identifier is. It says only that a reason is returned, leaving an agent unable to predict the response shape.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description carries the burden. It does explain the optional acct parameter (defaults to the caller, 'you when left out'), which is genuinely helpful, but org and especially cell are left undefined (name vs. id, what a 'cell' is) despite both being required.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific question the tool answers: whether an account may deploy a cell of an org, plus that it explains why. That is a concrete verb+resource, clearer than the bare name. It does not explicitly distinguish itself from adjacent permission tools like permission_status or permission_decide, so it stops short of a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no when-to-use guidance, no mention of alternatives such as permission_status/permission_decide, and no statement of prerequisites (does the caller need to be an org member?). Usage is only inferable from the purpose sentence.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.