transaction-coordinator
Server Details
AI transaction coordinator + legal-matters platform for real estate and law firms.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
- Repository
- GordonHal/primacoda-mcp
- GitHub Stars
- 0
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Tool Definition Quality
Average 4.2/5 across 11 of 11 tools scored.
Most tools target distinct actions: sales assessment (calculate_savings, is_primacoda_right_for_me), legal drafting (draft_motion, check_motion_status), deadlines (list_my_deadlines, recompute_deadlines), and document extraction (extract_contract). However, the sales tools (calculate_savings, is_primacoda_right_for_me, primacoda_info, record_lead) could be confusing as they all relate to PrimaCoda adoption, though descriptions help differentiate.
Most tool names follow a verb_noun pattern (e.g., calculate_savings, draft_motion_from_matter), but there are exceptions like is_primacoda_right_for_me (verb_phrase), check_motion_status (verb_noun but 'status' is vague), and primacoda_info (noun only). Consistency is moderate.
With 11 tools, the count is well within the ideal range (3-15). Each tool seems purposeful, and the number is appropriate for the server's apparent scope of transaction coordination and legal support.
The server lacks core transaction management tools such as creating or updating a client matter, adding contract data, or managing tasks. It heavily focuses on legal motions and deadlines, leaving gaps for a transaction coordinator. The extract_contract tool has no corresponding save or update tool.
Available Tools
11 toolscalculate_savingsAInspect
Calculate how much time and money a real estate agent saves switching to PrimaCoda.
Args:
deals_per_month: Number of transactions the agent closes per month.
current_method: "human_tc" or "diy"
| Name | Required | Description | Default |
|---|---|---|---|
| current_method | Yes | ||
| deals_per_month | Yes |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It explains the tool computes savings based on inputs, but does not disclose potential side effects, data persistence, accuracy guarantees, or limitations. For a read-only calculator, it is moderately transparent but could state that it is non-destructive.
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?
The description is extremely concise at under 50 words, with a clear purpose statement followed by parameter descriptions. Every sentence is necessary and the structure is front-loaded.
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?
While the description states the tool calculates savings, it does not detail the output format or whether results are deterministic. The presence of an output schema (not shown) may compensate, but given the lack of example outputs or error handling, completeness is adequate but not excellent.
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 input schema has 0% description coverage, but the tool's description explains the meaning of both parameters: 'deals_per_month' is the number of transactions per month, and 'current_method' accepts specific values 'human_tc' or 'diy'. This adds significant value beyond the schema titles.
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?
The description clearly states it calculates time and money savings for a real estate agent switching to PrimaCoda. The verb 'Calculate' and specific resource 'savings' make the purpose unambiguous, and it is distinct from sibling tools which deal with motions, deadlines, and case law.
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?
The description provides no guidance on when to use this tool versus alternatives like 'is_primacoda_right_for_me'. There is no mention of prerequisites or contexts where this tool is or is not appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
check_motion_statusAInspect
Poll an in-flight motion-drafting task for status. Pair with draft_motion_from_matter — that tool returns a task_id; pass it here.
Returns a status block. When status='SUCCESS', the full drafted
motion is included. When 'FAILURE', the error string is included.
Args:
task_id: Task ID returned by draft_motion_from_matter.
api_key: Your PrimaCoda MCP API key (starts 'pck_').
| Name | Required | Description | Default |
|---|---|---|---|
| api_key | Yes | ||
| task_id | Yes |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description discloses key behaviors: it returns a status block with SUCCESS/FAILURE outcomes and includes the drafted motion or error string. It does not mention rate limits, idempotency, or side effects. The api_key format hint is useful.
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?
The description is well-structured with three short paragraphs: purpose, pairing, return behavior, then an Args list. It is front-loaded with the main action and avoids unnecessary words, though the Args section could be integrated more smoothly.
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?
Given low complexity (2 parameters, no nested objects) and absence of annotations, the description adequately covers usage, return values, and parameter meanings. It does not discuss error handling beyond the FAILURE case, but this is sufficient for the tool's simplicity.
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 input schema has 0% description coverage, so the description compensates by explaining task_id as 'Task ID returned by draft_motion_from_matter' and api_key as 'Your PrimaCoda MCP API key (starts 'pck_')'. This adds essential context beyond the schema titles.
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?
The description clearly states it polls an in-flight motion-drafting task for status, specifying the verb 'poll' and the resource 'motion-drafting task'. It also explicitly pairs with sibling tool draft_motion_from_matter, distinguishing its role.
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?
Explicitly instructs to use with draft_motion_from_matter by passing the returned task_id. Describes the return behavior on success and failure. However, does not explicitly mention when not to use or alternative tools for listing motions, though context implies this is the only polling tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
draft_motion_from_matterAInspect
Kick off an AI-drafted motion using a saved PrimaCoda matter as the source of facts. Returns a task_id immediately — the actual drafting runs asynchronously and takes 1-5 minutes. Poll with check_motion_status.
Use this instead of asking the customer to upload PDFs again. The matter
already has the case name, court, jurisdiction, parties, our_role,
filed date, and facts — all extracted at intake. Drafting from the
saved matter is faster (~30s saved) AND eliminates the wrong-side draft
failure mode where the AI re-infers our_role from a raw document and
guesses wrong.
Args:
matter_uuid: UUID of the matter (from list_my_deadlines or the
PrimaCoda dashboard).
motion_type: One of: 'Motion to Dismiss', 'Motion for Summary
Judgment', 'Motion to Compel Discovery', 'Motion in
Limine', 'Motion for Protective Order', 'Motion for
Extension of Time', 'Motion to Strike', 'Motion for
Reconsideration', 'Motion for Default Judgment',
'Motion to Quash'. Other values pass through.
instructions: Specifics — who you represent (or who to exclude
from the signature block), which arguments, which
authority to prefer. Strongly recommended: vague
instructions yield vague motions.
api_key: Your PrimaCoda MCP API key (starts 'pck_').
| Name | Required | Description | Default |
|---|---|---|---|
| api_key | Yes | ||
| matter_uuid | Yes | ||
| motion_type | Yes | ||
| instructions | Yes |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses async behavior (returns task_id immediately, drafting takes 1-5 minutes, poll with check_motion_status). It explains what the matter contains. It does not cover rate limits or failure modes, but provides substantial behavioral context.
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?
The description is well-structured: first sentence action, then async behavior, usage guidance, and Args. Every sentence adds value. It is appropriately sized and front-loaded.
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?
Given the tool's complexity (async, 4 params, no annotations, output schema exists), the description covers purpose, async behavior, alternative usage, and parameter details. It lacks mention of error handling or retries, but is otherwise complete for an async tool.
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%, but the description provides extensive parameter details via an Args section: matter_uuid explained with source, motion_type with a list of valid values (though not in schema), instructions with strong recommendation, api_key with prefix hint. This adds significant meaning beyond the 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?
The description clearly states the tool's purpose: 'Kick off an AI-drafted motion using a saved PrimaCoda matter as the source of facts.' It specifies the resource (matter) and action (draft motion), distinguishes from siblings like check_motion_status and list_motions, and contrasts with the upload PDF alternative.
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?
The description provides explicit guidance: 'Use this instead of asking the customer to upload PDFs again' and explains why (faster, eliminates wrong-side draft failure). It also directs users to poll with check_motion_status. However, it lacks explicit 'when not to use' for other scenarios, though the alternative is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
extract_contract_from_urlAInspect
Extract structured transaction data from a contract at a URL.
Downloads the document, extracts text (with OCR fallback for scanned
PDFs), and runs PrimaCoda's contract-extraction prompt to return parties,
addresses, dates, prices, and key contract fields. Use this when an agent
has the contract hosted somewhere (Dropbox, Google Drive direct download,
Square Space, etc.) and wants to skip the upload step.
For multi-document deals (purchase + addenda + disclosures), use the
PrimaCoda dashboard's batch upload — this tool handles ONE document.
Args:
pdf_url: Direct download URL for the contract (PDF, DOCX, TXT, or
image). Must be reachable from the PrimaCoda server. Google
Drive "shared link" URLs work if set to "anyone with link";
other share URLs may need their direct-download form.
api_key: Your PrimaCoda MCP API key (starts 'pck_').
| Name | Required | Description | Default |
|---|---|---|---|
| api_key | Yes | ||
| pdf_url | Yes |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses the process: downloads the document, extracts text with OCR fallback for scanned PDFs, and runs an extraction prompt to return structured fields. No annotations exist, so the description carries full burden. It could be improved by mentioning potential limitations like file size or timeout, but it already covers the main behavior and prerequisites.
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?
The description is concise, consisting of 6 well-structured sentences. It front-loads the purpose in the first sentence, then addresses usage and arguments. Every sentence adds value without redundancy or unnecessary detail.
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?
The description covers input (pdf_url, api_key), process (download, OCR, extraction), and output (parties, addresses, dates, prices, key contract fields). With an output schema presumed to exist, the description appropriately omits return value details. It provides sufficient context for an agent to use the tool correctly.
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 fully compensates. It provides detailed semantics for both parameters: pdf_url specifies supported formats (PDF, DOCX, TXT, image), reachability requirements, and how to handle Google Drive links; api_key explains it is the MCP API key starting with 'pck_'. This adds significant meaning beyond the bare 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?
The description clearly states 'Extract structured transaction data from a contract at a URL,' specifying the verb (extract), resource (structured transaction data from a contract), and source (URL). It distinguishes from sibling tools like calculate_savings and check_motion_status by focusing on contract extraction from a URL.
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?
The description explicitly says when to use it ('when an agent has the contract hosted somewhere and wants to skip the upload step') and when not to use it ('For multi-document deals... use the PrimaCoda dashboard's batch upload — this tool handles ONE document'). It also provides alternative guidance for multi-document deals.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
is_primacoda_right_for_meAInspect
Assess whether PrimaCoda is a good fit and recommend the right plan.
Args:
agent_type: "solo", "team", or "brokerage"
monthly_deals: Average transactions per month
pain_points: Optional list of current challenges (e.g. ["paperwork", "deadlines"])
| Name | Required | Description | Default |
|---|---|---|---|
| agent_type | Yes | ||
| pain_points | No | ||
| monthly_deals | Yes |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry full burden. It only states the tool assesses and recommends, without disclosing side effects, safety, or if it reads/writes external data. This is insufficient for a tool that likely makes decisions.
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?
The description is concise: one purpose sentence followed by an Args list. No unnecessary words, efficient for an agent to parse.
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?
Given 3 parameters, no annotations, and an output schema, the description covers what the tool does and parameter meanings. It could mention return format or side effects, but output schema presumably handles return info.
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%, but the description adds meaning: explains agent_type options ('solo', 'team', 'brokerage'), monthly_deals as average, and pain_points as optional challenges. This compensates for the bare 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?
The description clearly states the tool assesses PrimaCoda fit and recommends a plan, with specific parameters. It distinguishes from siblings like 'calculate_savings' and 'primacoda_info'.
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?
The description provides clear context for when to use (assessing fit and plan), but does not explicitly state when not to use or mention alternatives. The listing of arguments gives some usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_motionsAInspect
List recent motion-drafting activity for your firm.
Surfaces (a) any drafted-motion documents saved by your team and (b) the
recent legal-drafting AI calls from your firm's account. Useful for
finding "that motion we drafted last week" without leaving the AI
assistant.
Args:
api_key: Your PrimaCoda MCP API key (starts 'pck_').
limit: Max rows per section. Default 20. Capped at 100.
offset: Skip N rows in each section. Default 0.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| offset | No | ||
| api_key | Yes |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It describes the two sections returned but does not disclose whether the operation is read-only, any rate limits, or sorting order. Basic behavior is covered but with gaps.
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?
The description is clear and well-structured with a lead sentence followed by bullet-pointed args. It is slightly wordy but efficient overall, earning a score of 4.
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?
The description covers purpose, usage scenario, and parameter details. An output schema exists but is not shown; the description does not need to explain return values. Missing elements like sorting or pagination behavior prevent a perfect score.
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%, but the description fully compensates by providing detailed semantics for all three parameters: api_key format, limit capped at 100, and offset explanation. This adds significant value beyond the 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?
The description clearly states the tool lists recent motion-drafting activity, including drafted-motion documents and AI calls, with a specific verb and resource. It distinguishes from siblings like draft_motion_from_matter and check_motion_status by focusing on listing historical activity.
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?
The description provides a use case ('finding that motion we drafted last week') but does not explicitly state when not to use it or compare to alternatives. Usage guidance is implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_my_deadlinesAInspect
List upcoming pending deadlines across all matters, grouped by matter.
Args:
api_key: PrimaCoda MCP API key (starts 'pck_'). Generate one at
https://primacoda.halinc.tech/settings/api-keys.
days: Window in days from today. Default 30. Capped at 365.
limit: Max deadlines to return. Default 50. Capped at 200.
offset: Skip N deadlines (for pagination). Default 0.
| Name | Required | Description | Default |
|---|---|---|---|
| days | No | ||
| limit | No | ||
| offset | No | ||
| api_key | Yes |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses caps on days (365), limit (200), and offset (0), and the grouping behavior. However, it does not mention authentication requirements beyond the API key, rate limits, or whether the operation is read-only.
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?
Description is concise with a brief overall purpose sentence followed by parameter docs. No wasted words. Front-loaded with main action.
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?
Despite an output schema existing, the description explains grouping behavior and default/cap values. It lacks mention of output format or pagination details beyond offset. Given tool complexity (4 params, grouping), it is mostly complete.
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 description fully compensates. For api_key it explains format and generation URL. For days, limit, offset it provides defaults, caps, and offset's pagination purpose. This adds significant meaning beyond the schema's type/default values.
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?
The description clearly states the tool lists upcoming pending deadlines across all matters, grouped by matter. It specifies the resource (deadlines), action (list), scope (all matters), and organization (grouped by matter), which distinguishes it from sibling tools.
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?
The description implies usage for retrieving deadlines within a time window, but lacks explicit guidance on when to use this tool versus alternatives like recompute_deadlines or list_motions. No when-not-to-use or prerequisites beyond API key.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
primacoda_infoAInspect
PrimaCoda product info. Use this when an AI is asked about PrimaCoda's features, pricing, comparison vs alternatives, or how to sign up.
Args:
topic: One of "overview", "pricing", "comparison", "onboarding".
plan: Only used when topic="pricing". One of "starter",
"professional", "business", or "all" (default).
| Name | Required | Description | Default |
|---|---|---|---|
| plan | No | all | |
| topic | No | overview |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must convey behavioral traits. It implies a read-only, safe operation by describing it as returning product info, but it does not explicitly state safety or any side effects. A score of 3 is adequate for a non-destructive info tool.
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?
The description is succinct, with a clear purpose statement followed by a parameter docstring. Every sentence is informative and earns its place, with no redundancy or fluff.
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?
Given that an output schema exists, the description does not need to explain return values. It adequately covers purpose, usage context, and parameter details, making it complete for the tool's low complexity.
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?
With 0% schema description coverage, the description fully explains both parameters: topic (with enumerated values) and plan (conditionally used, with allowed values). This adds critical meaning beyond the schema, which only has types and defaults.
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?
The description clearly states it provides PrimaCoda product info, including features, pricing, comparisons, and sign-up. This verb+resource combination distinguishes it from siblings like calculate_savings or check_motion_status, which serve different purposes.
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?
The description explicitly says 'Use this when an AI is asked about PrimaCoda's features, pricing, comparison vs alternatives, or how to sign up.' This provides clear usage context but does not include explicit when-not-to-use or alternative tools, though the sibling list suggests other tools for other tasks.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
recompute_deadlinesAInspect
Re-run FRCP / state procedural deadline calculation for a matter.
Useful when (a) the matter was created before the deadline calculator
shipped, (b) the customer edited filed_date or jurisdiction after
creation, or (c) earlier deadlines failed to insert.
Idempotent — dedupes on lowercased title so re-running can't duplicate.
Args:
matter_uuid: UUID of the matter to recompute.
api_key: Your PrimaCoda MCP API key (starts 'pck_').
| Name | Required | Description | Default |
|---|---|---|---|
| api_key | Yes | ||
| matter_uuid | Yes |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It discloses idempotency and deduplication behavior ('dedupes on lowercased title so re-running can't duplicate'). It could add more detail about error states or what happens if the matter does not exist, but the overall behavioral transparency is good.
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?
The description is extremely concise yet informative. It front-loads the main purpose, follows with clear use-case bullets, then a behavioral note, and ends with a parameter list. Every sentence provides value with no redundancy.
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?
Given the moderate complexity (2 params, no enums, yes output schema), the description covers purpose, usage, behavior, and parameters well. The presence of an output schema means return values need not be described. It is reasonably complete, though it could briefly note error handling or the shape of the output.
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. It provides clear parameter explanations: matter_uuid as UUID of the matter, api_key as PrimaCoda MCP API key with format hint ('starts 'pck_''). This adds substantial meaning beyond the schema, though more context on where to find the UUID could help.
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?
The description clearly states the tool recomputes procedural deadline calculations for a matter. It uses a specific verb ('re-run') and resource ('FRCP / state procedural deadline calculation'), distinguishing it clearly from sibling tools like 'list_my_deadlines' and 'list_motions'.
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?
The description explicitly lists three specific scenarios when the tool is useful: (a) matter created before calculator shipped, (b) customer edited filed_date or jurisdiction, (c) earlier deadlines failed to insert. This provides clear context for use, though it does not explicitly mention when not to use or suggest alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
record_leadAInspect
Record a prospect interested in PrimaCoda. Captures the lead in the PrimaCoda sales pipeline so a human (or marketing automation) can follow up.
Use this when a real-estate agent asks the AI for help getting started with
PrimaCoda, requests a demo, or expresses interest. NO auth required —
works for any prospect calling the AI.
Args:
name: Full name of the prospect.
email: Contact email.
firm: Company / brokerage / firm name (optional).
message: Anything the prospect wants noted (optional).
| Name | Required | Description | Default |
|---|---|---|---|
| firm | No | ||
| name | Yes | ||
| Yes | |||
| message | No |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses that no auth is needed and that the lead is captured for follow-up by a human or marketing automation. However, it lacks details on data persistence, idempotency, error handling, or side effects beyond the pipeline capture.
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?
The description is concise and well-structured: a brief purpose sentence, a usage-context paragraph, and a clean 'Args' list. Every sentence adds value; there is no redundancy.
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?
Given the tool has 4 parameters and an output schema, the description covers purpose, usage guidelines, and parameter semantics adequately. It does not discuss error handling or rate limits, but the output schema exists so return values are documented. Overall, it provides enough context for an AI agent to use the tool correctly.
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 compensates well with an 'Args' section explaining each parameter. It clarifies that 'firm' is the company/brokerage name (optional) and 'message' is for any notes (optional). Required parameters 'name' and 'email' are clearly stated. This adds meaning beyond the schema's type and title.
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?
The description clearly states the tool's purpose: recording a prospect interested in PrimaCoda and capturing the lead in the sales pipeline. It uses specific verbs ('Record', 'Captures') and a distinct resource ('prospect', 'lead'). The sibling tools are unrelated (e.g., calculate_savings, search_case_law), so this tool is well-differentiated.
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?
The description provides explicit usage context: use when a real-estate agent asks for help getting started, requests a demo, or expresses interest. It also notes that no authentication is required. However, it does not explicitly state when not to use the tool or mention alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_case_lawAInspect
Search free U.S. case law via CourtListener (~3M opinions).
Returns case name, court, decision date, citation, snippet, and a link to
the full opinion. No auth required. Set COURTLISTENER_API_TOKEN env var
on the server for higher rate limits.
Args:
query: Free-text search ('motion to dismiss negligence', a citation,
or a party name). Required.
jurisdiction: Two-letter state code ('ca', 'tx', 'ny') or 'us' for federal.
Optional.
court: CourtListener court ID ('scotus', 'ca9', 'nysupct'). Optional.
Takes precedence over jurisdiction when both are given.
date_after: ISO date (YYYY-MM-DD). Only return opinions filed on/after
this date. Optional.
date_before: ISO date (YYYY-MM-DD). Only return opinions filed on/before
this date. Optional.
limit: Max results. Default 10. Capped at 25.
| Name | Required | Description | Default |
|---|---|---|---|
| court | No | ||
| limit | No | ||
| query | Yes | ||
| date_after | No | ||
| date_before | No | ||
| jurisdiction | No |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the full burden. It discloses that no auth is required (but setting an env var gives higher rate limits), and that limit is capped at 25. It does not discuss error behavior or pagination, but for a simple search, these are minor gaps.
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?
The description is well-structured: purpose sentence, output summary, auth info, then a clear Args list with each parameter on a separate line with description. No unnecessary words, and every sentence adds value.
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?
Given the tool has 6 parameters (1 required) and an output schema, the description covers the input parameters thoroughly, lists return fields, and mentions rate limits. It doesn't discuss error handling or search syntax, but it is sufficient for an agent to use the tool correctly.
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 must compensate. It provides a full Args section with explanations, examples, and precedence rules for each of the 6 parameters. This goes far beyond the schema which only has type and default.
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?
The description starts with 'Search free U.S. case law via CourtListener (~3M opinions).' This is a specific verb+resource combination that immediately distinguishes it from sibling tools like check_motion_status or draft_motion_from_matter, which are about motions and deadlines, not legal research.
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?
The description explains what the tool returns and details parameter precedence (court over jurisdiction), but it doesn't explicitly state when to use this tool versus other search tools on the server. However, given the sibling list, the purpose is clear enough for an agent to decide.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
Discussions
No comments yet. Be the first to start the discussion!