Skip to main content
Glama
Sign In

Awning

by help.awning
OverviewDiscussionsAdmin

Approve or reject an application

op_decide_application
Destructive

Only for the Awning team. approve publishes the business; reject needs a note the owner will see. To approve an application of any route but rename, pass expected_name: the business's name exactly as op_applications showed it to you (business.name). The owner can change the name while the application waits, so approving is refused when the business is called something else now: list the applications again, check the name, then decide. For route rename, approve gives the business the new name from the request and changes nothing else (no expected_name needed), and reject keeps the current name. recall applies to an approved application with route auto_branch — a new location that went live without review: it leaves the catalogue and returns to the queue as a new application. Use it only for an application op_applications listed, after checking its warnings.

Input Schema

NameRequiredDescriptionDefault
noteNoRequired to reject: the owner sees it. Optional otherwise.
decisionYesapprove publishes the business; reject sends the note to the owner; recall takes an auto_branch location back to review
expected_nameNoTo approve: the business name you were shown in op_applications. Required unless the route is rename.
application_idYesThe application: application_id from op_applications

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changed
    • addedInput schema / properties / application_id / description
      Added value: +"The application: application_id from op_applications"
    • addedInput schema / properties / decision / description
      Added value: +"approve publishes the business; reject sends the note to the owner; recall takes an auto_branch location back to review"
    • addedInput schema / properties / note / description
      Added value: +"Required to reject: the owner sees it. Optional otherwise."
  2. Changed1 schema field changed
    • addedInput schema / properties / expected_name
      Added value: +{
+  "description": "To approve: the business name you were shown in op_applications. Required unless the route is rename.",
+  "maxLength": 200,
+  "type": "string"
+}
  3. Changed1 schema field changed
    • changedInput schema / properties / decision / enum
      Previous value: -[
-  "approve",
-  "reject"
-]New value: +[
+  "approve",
+  "reject",
+  "recall"
+]
  4. First observed

TDQS

A4.4/5.0
Behavior5/5

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

Beyond the destructiveHint/openWorldHint annotations, it discloses consequences that matter: approval makes the business publicly live, rejection sends the note to the owner, approval is refused if the name changed, and recall removes the business from the catalogue and recreates the application. It also names the access restriction ('Only for the Awning team'), which the annotations do not capture.

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?

Dense but nearly every sentence carries a distinct rule; the expected_name rationale is front-loaded with its consequence. Slightly long-winded in places ('list the applications again, check the name, then decide') but no filler paragraphs.

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 mutation tool with no output schema and four fully documented parameters, it covers decision outcomes, the stale-name failure mode, the rename special case, and recall's effect. Route concepts like 'auto_branch' and 'rename' are used without definition, relying on op_applications for that vocabulary.

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, but the description adds real meaning: expected_name must be the exact name shown by op_applications (business.name), is unnecessary for the rename route, and is validated against the current name. It also explains the owner-visible effect of note on reject.

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 enumerates the three outcomes concretely: 'approve publishes the business', 'reject needs a note the owner will see', and recall returns an auto_branch location to the queue. It is clearly distinct from op_applications (which lists) and op_decide_lead (different resource). It loses a point only because it opens with an audience restriction rather than a one-line statement of what the tool does.

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 gives explicit when-to-use rules per decision, including the expected_name requirement and its exception for the rename route, and the narrow condition for recall ('only for an application op_applications listed, after checking its warnings'). It also gives a recovery path when approval is refused: list applications again, re-check the name, then decide.

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

All Awning 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