Review contracts for risks: summary, severity-rated flags, key terms, and clause coverage.
The last two health checks of this connector failed. If this server requires authentication, missing or expired test credentials may be the cause. A test profile lets Glama authenticate for health checks and discover tools; it is separate from your personal connections.
If you are the author, claim ownership, then add or update a test profile under Admin → Test Profile.
Scored across 2 tools
The two tools are unmistakably distinct: analyze_contract performs the heavy analytical work on a document, while check_usage reports organizational quota. There is no plausible scenario in which an agent confuses a metered analysis call with a free usage lookup.
Both names follow a clean verb_noun snake_case pattern (analyze_contract, check_usage), with consistent lowercase and underscore separators. The convention is predictable even though the set is tiny.
Two tools is thin for a server branded as 'Contract Intelligence' that also hints at other metered operations (e.g. theme extraction over many reviews). The surface is essentially one capability plus a quota check, leaving little room for the broader workflow implied by the descriptions.
The server can analyze a contract and report usage, but there is no way to retrieve, list, compare, or re-fetch prior analyses, and no batch or multi-contract entry point despite the persistent content hash implying stored results. Agents hit dead ends for anything beyond a single one-shot first pass.
First-pass review of ONE contract: plain-language summary, risk flags (with severity low|medium|high and explanations), key terms (parties, dates, term, termination notice, governing law, payment terms, auto-renewal), and presence/absence of 8 standard clauses with verbatim evidence excerpts. Input: raw contract text 100-150,000 chars (≤50,000 on the Free plan); optional title, counterparty, and document_type (msa|nda|sow|employment|lease|services|license|other). Raw text is never stored — only a content hash and the structured result. METERED — the most expensive WizerAPI operation: 12 AU + 1 AU per 1,250 chars (a 30,000-char contract ≈ 36 AU; the 150,000-char max ≈ 132 AU). Call check_usage BEFORE long documents. Re-analyzing byte-identical text in the same organization is 0 AU (cached: true). Every result reports its au_cost. Automated first-pass assistance, NOT legal advice.
| Name | Required | Description | Default |
|---|---|---|---|
| text | Yes | ||
| title | No | ||
| counterparty | No | ||
| document_type | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does so: it discloses data retention ('Raw text is never stored — only a content hash and the structured result'), metering with a concrete pricing formula and worked examples, plan-based input limits, caching behavior, and that every result reports au_cost. That is far more behavioral context than most definitions provide.
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?
Front-loaded with purpose and output shape before constraints and pricing, and every element is substantive rather than filler. It is, however, a single dense paragraph with stacked parentheticals (severity, enum values, pricing math), which taxes parsing compared to a lightly structured form.
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?
For a 4-parameter, no-output-schema, no-annotation tool, the description covers inputs, outputs, cost, retention, plan limits, caching, and the legal-advice boundary. An agent has everything needed to decide whether to call it, what to send, and what to expect back.
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 description coverage is 0%, so the description must compensate, and it largely does: it states the text range (100–150,000 chars, ≤50,000 on Free) and lists all eight document_type enum values. The remaining gap is that it never explains how document_type affects the analysis (e.g., which clauses are checked), leaving that choice unmotivated.
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 verb (first-pass review) and a tightly scoped resource (ONE contract), then enumerates exactly what the tool produces: summary, risk flags with severity, key terms, and presence/absence of 8 standard clauses with evidence excerpts. It is immediately distinguishable from the only sibling, check_usage, which it references explicitly.
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?
Gives when-to-use (first-pass review of a single contract), an explicit gating instruction ('Call check_usage BEFORE long documents'), and the condition that changes the decision (byte-identical re-analysis is 0 AU / cached:true). The 'ONE contract' framing and the 'NOT legal advice' disclaimer also set boundaries on when this tool is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check the current billing period usage for YOUR WizerAPI organization: plan, included AU, used AU, remaining AU, overage so far, and the per-minute rate limit. Costs 0 AU and is never blocked by the session budget. Call this BEFORE large metered jobs (theme extraction over many reviews, long contracts) to confirm quota headroom, and AFTER quota errors to see where you stand.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does well: it discloses that the call costs 0 AU and is never blocked by the session budget, which is critical non-obvious behavior for a metered API. It does not explicitly label the operation read-only or describe auth requirements, leaving a small 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?
Two sentences, front-loaded with the resource and its returned fields, then the timing guidance. Dense and mostly waste-free, though the long list of return values is slightly inventory-like.
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?
No output schema exists, but the description enumerates the returned values, and with no annotations it covers cost and budget behavior. What remains thin is the operational boundary: auth/scope requirements for 'YOUR organization' are only implied.
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?
The tool takes zero parameters, so the baseline is 4; there is no parameter semantics to add and the description correctly adds none. The enumerated return fields substitute usefully for a missing output schema.
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 verb (check) and resource (billing period usage for the organization) and enumerates exactly what is reported: plan, included AU, used AU, remaining AU, overage, and per-minute rate limit. An agent can distinguish it from the only sibling, analyze_contract, without opening either schema.
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?
Gives explicit invocation timing: before large metered jobs (with concrete examples like theme extraction over many reviews, long contracts) and after quota errors. No when-not-to-use condition or named alternative, but the lone sibling is not a plausible substitute, so the guidance is effectively complete.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
analyze_contractcheck_usageContract review that keeps your contracts: cited answers, Word redlines, key-date alerts.
Import, review and track renewals on your business contracts from your AI assistant.
Contract drafting, statute-cited US state law requirements, non-compete checks, risk analysis.
Run deterministic SaaS contract redlining, GDPR Art. 28 DPA & EU AI Act compliance audits.
Add one secure layer between your agents and this server.
