Skip to main content
Glama
Sign In

aurgus

by com.aurgus
OverviewDiscussionsAdmin

compose_agreement

Build a rebate/incentive agreement by talking it through — no document needed. Describe the program in plain words and Aurgus DRAFTS the terms (who qualifies, how volume is measured and over what period, the threshold, the rate or per-unit reward, any cap, and approval routing) and asks the consultant-style questions a controller would ask before assuming. IMPORTANT: these terms are DRAFTED by the model from your words — they are PROPOSED, NOT PARSED, and nothing is created. When the terms are right, call again with finalize=true and the reviewed proposal, and Aurgus stages it for a person with approval authority to approve in the browser (you can NOT approve your own). This is how you establish an agreement (ASC 606 step 1) when you have no document — before any transaction data is asked for. When a document exists, prefer ingest_agreement (its deterministic parser touches the numbers with zero LLM).

Input Schema

NameRequiredDescriptionDefault
finalizeNoSet true ONLY after the terms have been reviewed and the follow-ups resolved. Stages the proposal for human approval; omit/false to just draft and refine.
proposalNoRequired when finalize=true: the EXACT drafted proposal returned by a prior (non-finalize) call, echoed back verbatim — so what is staged is exactly what was reviewed. Staging does NOT re-run the model.
descriptionYesPlain-language description of the program — who it's for, how it's measured and over what period, the rate/threshold/cap, the dates. On the first turn, just describe it.
clarificationsNoAnswers to the follow-up questions from a previous turn, so the draft refines. Each item pairs the question asked with the answer.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.8/5.0
Behavior5/5

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

Goes well beyond readOnlyHint=false: it states terms are PROPOSED not PARSED, that nothing is created on draft, that finalize stages for a human approver, and that the caller cannot self-approve. These are critical behavioral traits an agent would otherwise guess wrong.

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?

Front-loaded with the core action and the draft/not-created caveat, and every sentence carries weight. Slightly heavy with capitalized emphasis that could be trimmed, but the density is justified by the multi-turn protocol it must convey.

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?

No output schema exists, yet the description fully explains the conversational loop, what is returned (drafted terms + follow-up questions), and the staging/approval outcome. An agent has everything needed to invoke it correctly across turns.

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: finalize should be true only after review, proposal must be echoed verbatim from a prior call, and clarifications resolve follow-ups. This clarifies the multi-turn protocol beyond what the field-level schema states.

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?

States a specific verb+resource ('Build a rebate/incentive agreement by talking it through') and immediately distinguishes it from its nearest sibling (ingest_agreement). An agent can tell exactly what this tool produces — a drafted proposal, not a created record — without opening the schema.

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?

Explicitly names when to use it (no document, ASC 606 step 1, before transaction data) and when not to (when a document exists, prefer ingest_agreement with its deterministic parser). It also explains the two-turn draft→finalize loop, so the agent knows the sequencing.

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

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