ClearPolicy
Server Details
ClearPolicy is a document signing and compliance tracking tool for organizations. Once connected, your AI assistant can import documents, send signature requests, track who has and hasn't signed, and manage your contacts — all by prompt.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
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/5 across 13 of 13 tools scored.
Each tool targets a distinct action and resource. There is no overlap; for example, 'create-person' adds a person, while 'add-person-to-group' assigns them to a group, and the various list/get tools are clearly separated by entity type.
All tool names follow a consistent pattern: lowercase with hyphens, verb-phrase ending in '-tool'. The structure is predictable and readable, e.g., list-documents-tool, get-person-tool, send-signing-request-tool.
13 tools is well within the ideal 3-15 range. Each tool covers a necessary operation for the domain of managing people, groups, documents, and signing requests without being excessive.
The tool set covers the core workflow: managing people, groups, documents, and signing requests. Minor gaps like missing update/delete for people, groups, and documents are acceptable since the focus is on sending and tracking signatures, not full CRUD.
Available Tools
13 toolsadd-person-to-group-toolAdd Person To Group ToolAIdempotentInspect
Add one person to a ClearPolicy group. When the group has automatic request issuance enabled, this assigns the group documents and sends the grouped attestation request notification for newly assigned published documents.
| Name | Required | Description | Default |
|---|---|---|---|
| group_id | Yes | The ULID of the group to add the person to. | |
| person_id | Yes | The ULID of the active person to add to the group. |
Output Schema
| Name | Required | Description |
|---|---|---|
| added | Yes | |
| group | No | |
| person | No | |
| attestation_requests | Yes | |
| new_assignments_count | Yes | |
| attestation_requests_count | Yes | |
| notification_batches_count | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate idempotent and non-destructive. The description adds that adding a person can trigger document assignment and notification under a specific condition, which is useful behavioral context beyond the annotations.
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 concise sentences, front-loaded with the primary action and a secondary conditional effect. No wasted words.
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 tool with two string parameters, schema descriptions, annotations, and output schema, the description provides sufficient context. It covers the main action and a key conditional behavior, though it could mention the idempotency (already in annotations).
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 100% with descriptions for group_id and person_id already provided. The description does not add additional semantic information about the parameters beyond what's in 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 adds one person to a ClearPolicy group, specifying the resource and action. It also mentions conditional behavior when automatic request issuance is enabled, distinguishing it from other group-related 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 provides a conditional scenario (automatic request issuance) but lacks explicit guidance on when to prefer this tool over siblings like list-groups or create-person. No when-not or alternative tools are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
cancel-signing-request-toolCancel Signing Request ToolADestructiveIdempotentInspect
Cancel a pending signature or acknowledgment request. This cannot be undone.
| Name | Required | Description | Default |
|---|---|---|---|
| request_id | Yes | The ULID of the signing request to cancel. |
Output Schema
| Name | Required | Description |
|---|---|---|
| message | Yes | |
| success | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint=false, destructiveHint=true, and idempotentHint=true. The description adds 'This cannot be undone' and specifies 'pending' requests, but adds little beyond what annotations convey.
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 concise, front-loaded sentences with no filler. Every word earns its place.
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 simple cancel action with one parameter and a destructive hint, the description adequately covers the core behavior and irreversibility. Minor missing details like return value are likely covered by the output schema.
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 100% with clear parameter documentation. The description does not add additional meaning to the parameters, so baseline 3 is appropriate.
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 'Cancel a pending signature or acknowledgment request' using a specific verb and resource. It distinguishes from sibling tools like send-signing-request-tool and list-signing-requests-tool.
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 use for canceling pending requests but provides no explicit guidance on when to use or alternatives. The context is clear but lacks exclusions or comparisons.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
create-person-toolCreate Person ToolAInspect
Add a new person to the current ClearPolicy organization so they can be assigned documents, added to groups, and sent signature or acknowledgment requests.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Full name of the person. | |
| Yes | Email address of the person. Must be unique within the organization. | ||
| phone | No | Phone number in international format (e.g. +12125551234). |
Output Schema
| Name | Required | Description |
|---|---|---|
| id | Yes | |
| name | Yes | |
| Yes | ||
| phone | No | |
| resource_uri | Yes | |
| groups_resource_uri | Yes | |
| documents_resource_uri | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations show this is a write operation (readOnlyHint=false). The description adds some behavioral context (future capabilities of the person) but doesn't disclose permissions, side effects, or unique constraints beyond what's in the schema.
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 a single, well-structured sentence that conveys all necessary information without any wasted words. It is front-loaded with the core 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?
The tool has an output schema, so the description doesn't need to explain return values. It covers the purpose and post-creation uses. Minor gap: no explicit mention of when to use vs siblings, but overall sufficient.
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 100%, so each parameter is already documented. The description adds no additional meaning beyond the schema, meeting the baseline for this dimension.
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 'Add a new person to the current ClearPolicy organization' with a specific verb and resource, and explains the purpose (assign documents, add to groups, send requests). It distinguishes from sibling tools like 'add-person-to-group-tool'.
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 (to add a new person). While it doesn't mention when not to use or list alternatives, the context is clear from the sibling tool names that this is for creation, not other operations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get-document-toolGet Document ToolARead-onlyIdempotentInspect
Get details of a document, including how many people have signed or acknowledged it and how many haven't.
| Name | Required | Description | Default |
|---|---|---|---|
| document_id | Yes | The ULID of the document. |
Output Schema
| Name | Required | Description |
|---|---|---|
| id | Yes | |
| name | Yes | |
| archived | Yes | |
| auto_renew | No | |
| attestation_counts | No | |
| current_version_id | No | |
| renewal_interval_days | No | |
| has_published_revision | Yes | |
| default_attestation_type | No | |
| current_version_published_at | No | |
| latest_published_revision_pdf_uri | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true. Description adds context about returned sign counts but doesn't reveal additional behavioral traits beyond annotations.
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?
Single sentence that is front-loaded with the core purpose, no unnecessary words, every sentence earns its place.
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 presence of an output schema, the description sufficiently covers the tool's purpose and key output specifics. No gaps for a simple retrieval 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 coverage is 100% with a clear parameter description ('The ULID of the document'). Description adds no extra meaning beyond the schema, so baseline score of 3.
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?
Description specifies 'Get details of a document' with specific content (sign/acknowledge counts), distinguishing it from sibling tools like list-documents-tool or get-signing-request-tool.
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?
Implies usage for retrieving detailed document info including sign counts, but lacks explicit 'when to use vs alternatives' guidance. Clear context but no exclusion statements.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get-group-toolGet Group ToolARead-onlyIdempotentInspect
Get details for one ClearPolicy group, including counts and resource URIs for its members and documents.
| Name | Required | Description | Default |
|---|---|---|---|
| group_id | Yes | The ULID of the group to retrieve. |
Output Schema
| Name | Required | Description |
|---|---|---|
| id | Yes | |
| name | Yes | |
| source | No | |
| source_id | No | |
| created_at | No | |
| updated_at | No | |
| description | No | |
| resource_uri | Yes | |
| last_synced_at | No | |
| documents_count | Yes | |
| recipient_message | No | |
| active_people_count | Yes | |
| members_resource_uri | Yes | |
| compliant_people_count | Yes | |
| documents_resource_uri | Yes | |
| automatic_request_issuance_enabled | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true. The description adds value by specifying that it includes 'counts and resource URIs for its members and documents', providing richer behavioral context beyond annotations.
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 sentence that efficiently conveys the tool's purpose and output specifics without any wasted words. All information is relevant 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?
For a simple read-only tool with one parameter, the description adequately covers what the tool does and what it returns. The presence of an output schema reduces the need to describe return values further.
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 single parameter group_id is fully described in the schema as 'The ULID of the group to retrieve.' The description does not add additional meaning beyond the schema, so baseline 3 is appropriate given 100% schema coverage.
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 states 'Get details for one ClearPolicy group' which is a specific verb and resource. It includes details like counts and resource URIs, distinguishing it clearly from list-groups-tool and other siblings.
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 a single group's details, which is clear given siblings like list-groups-tool. However, it does not explicitly state when not to use or mention alternatives beyond the implicit context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get-person-toolGet Person ToolARead-onlyIdempotentInspect
Get a person's profile and see which documents they have or haven't signed or acknowledged.
| Name | Required | Description | Default |
|---|---|---|---|
| person_id | Yes | The ULID of the person. |
Output Schema
| Name | Required | Description |
|---|---|---|
| id | Yes | |
| name | Yes | |
| Yes | ||
| phone | No | |
| archived | Yes | |
| document_counts | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true, so the agent knows it is a safe, idempotent read operation. The description adds behavioral context by specifying that the tool also shows which documents are signed or acknowledged, which is not captured in the annotations. This adds value beyond the annotations.
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 a single sentence that concisely captures the tool's purpose and additional scope. Every word adds value, and there is no superfluous information.
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 one parameter, strong annotations, and an output schema, the description sufficiently explains what the tool returns (profile and document status). It is complete for the tool's 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?
Schema description coverage is 100% for the single parameter 'person_id', which is already described as 'The ULID of the person.' The tool description does not add any additional meaning or context for the parameter beyond what is in the schema. Baseline score of 3 is appropriate.
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 'get a person's profile and see which documents they have or haven't signed or acknowledged.' It specifies the verb 'get' and the resource 'person's profile', and distinguishes from sibling tools like list-people-tool and get-document-tool by including the document signing/acknowledgment aspect.
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 a person's profile and their document status, but does not explicitly state when to use this tool versus alternatives. For example, it does not mention that list-people-tool should be used for listing all people, or that get-document-tool is for a specific document. No when-to-use or when-not-to-use guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get-signing-request-toolGet Signing Request ToolARead-onlyIdempotentInspect
Check whether a specific person has signed or acknowledged a document, and when.
| Name | Required | Description | Default |
|---|---|---|---|
| request_id | Yes | The ULID of the signing request. |
Output Schema
| Name | Required | Description |
|---|---|---|
| id | Yes | |
| person | No | |
| status | Yes | |
| sent_at | No | |
| document | No | |
| viewed_at | No | |
| expired_at | No | |
| expires_at | No | |
| attested_at | No | |
| canceled_at | No | |
| resource_uri | Yes | |
| attestation_type | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering safety. The description adds the specific behavioral trait of returning signing/acknowledgment status and timestamp, which is useful but not extensive.
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 a single 14-word sentence that is front-loaded with the key purpose. No unnecessary words. Highly efficient.
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 an output schema present, the description does not need to detail return values. The description covers the core purpose for a simple one-parameter tool. Lacks mention of error cases (e.g., request not found), but overall sufficient.
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 100% coverage with one parameter 'request_id' described as 'The ULID of the signing request.' The description adds no additional meaning or constraints beyond the schema, meeting the baseline.
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 'Check whether a specific person has signed or acknowledged a document, and when' clearly states the tool's action (check) and resource (signing request status), distinguishing it from siblings like cancel, list, or send.
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 checking signing status but does not explicitly state when to use this tool versus alternatives like list-signing-requests-tool or cancel-signing-request-tool. No when-not-to or context exclusions are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list-documents-toolList Documents ToolARead-onlyIdempotentInspect
Find documents available to send for employee signatures or policy acknowledgments. Use this to browse what documents the organization has ready to send.
| Name | Required | Description | Default |
|---|---|---|---|
| name | No | Filter documents by name (partial match, case-insensitive). | |
| include_archived | No | Include archived documents in the results. Defaults to false. |
Output Schema
| Name | Required | Description |
|---|---|---|
| documents | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering safety and idempotency. The description adds that the tool lists documents available to send but does not provide additional behavioral context (e.g., pagination, rate limits) beyond the annotations.
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 two sentences, front-loaded with the primary purpose, and contains no redundant information.
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 2 optional params and an output schema (not shown), the description covers the essential purpose. It is sufficiently complete for a straightforward listing tool with comprehensive annotations.
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 100%, so the schema already documents both parameters ('name' as partial match case-insensitive filter, 'include_archived' as boolean). The description adds no extra 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 lists documents available for sending for signatures or acknowledgments, with a verb ('Find'/'browse') and specific resource ('documents'). It distinguishes from siblings like 'get-document-tool' (single document) and 'list-signing-requests-tool' (requests, not documents).
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 indicates this tool is for browsing documents ready to send, implying when to use it. It does not explicitly state when not to use it or name alternatives, but the context from sibling tools is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list-groups-toolList Groups ToolARead-onlyIdempotentInspect
Find groups in the current ClearPolicy organization. Use this when an MCP client does not support resources or when the user asks to browse groups.
| Name | Required | Description | Default |
|---|---|---|---|
| name | No | Filter groups by name (partial match, case-insensitive). |
Output Schema
| Name | Required | Description |
|---|---|---|
| groups | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide readOnlyHint=true and destructiveHint=false, covering safety. Description adds scope ('current organization') but no additional behavioral traits like pagination or rate limits. No contradiction.
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: first defines purpose, second provides usage guidance. No redundant words, well-structured 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?
For a simple tool with one optional parameter, good annotations, and an output schema, the description provides sufficient context. Covers purpose, usage, and scope without missing critical details.
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 100%, and the parameter description in the schema already explains the filter behavior. The tool description does not add new information beyond what's in the schema, so baseline 3 is appropriate.
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?
Description clearly states the tool finds groups in the current ClearPolicy organization, with a specific verb and resource. It also distinguishes from siblings by mentioning when to use it, effectively differentiating it.
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 states when to use: when MCP client doesn't support resources or user asks to browse groups. Provides clear context, though doesn't explicitly mention when not to use or list alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list-people-toolList People ToolARead-onlyIdempotentInspect
Find people in the organization who can be sent documents for signature or acknowledgment. Search by name or email.
| Name | Required | Description | Default |
|---|---|---|---|
| name | No | Filter by name (partial match, case-insensitive). | |
| No | Filter by email address (partial match). | ||
| include_archived | No | Include archived people in the results. Defaults to false. |
Output Schema
| Name | Required | Description |
|---|---|---|
| people | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, assuring safe, non-destructive behavior. The description adds business context but does not disclose additional behavioral traits (e.g., pagination, default limits, or response structure). It does not contradict annotations.
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 two sentences long, front-loaded with the core purpose, and contains no fluff. Every sentence contributes meaning: the first states the goal, the second lists the search criteria.
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 simplicity, full parameter documentation, presence of an output schema, and annotations covering safety, the description is complete. It provides sufficient context for an AI agent to select and invoke this 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 description coverage is 100%, with all three parameters documented (name, email, include_archived). The description reiterates 'Search by name or email' but adds no extra semantic value beyond what the schema provides. Baseline 3 is appropriate.
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 explicitly states the tool's purpose: 'Find people in the organization who can be sent documents for signature or acknowledgment.' It specifies the search capabilities (by name or email) and distinguishes it from sibling tools like list-groups or list-documents, which serve different entities.
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 context by mentioning 'who can be sent documents', implying its use for initiating signing/acknowledgment workflows. However, it lacks explicit guidance on when to use this tool versus alternatives like get-person-tool (for a single person) or send-signing-request-tool. No when-not or direct comparisons are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list-signing-requests-toolList Signing Requests ToolARead-onlyIdempotentInspect
Check who has signed a document and who hasn't. Filter by document, person, or status (pending, signed, expired, etc.) to track compliance.
| Name | Required | Description | Default |
|---|---|---|---|
| status | No | Filter by status: created, sent, viewed, attested, expired, or canceled. | |
| person_id | No | Filter by person ULID. | |
| document_id | No | Filter by document ULID. |
Output Schema
| Name | Required | Description |
|---|---|---|
| requests | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, so the tool is clearly safe and idempotent. The description adds context about checking who signed vs. who didn't, but does not introduce any behavioral details beyond what annotations cover. No contradiction.
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 a single sentence with no unnecessary words. It front-loads the main purpose and efficiently lists filtering capabilities. Every part is informative.
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 list tool with three optional filters and full schema coverage, the description is complete. It explains the purpose and filtering options adequately. An output schema exists (not shown but present), so return values are covered. Sibling tools are many, but this description clearly differentiates.
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 100% (all parameters documented in schema). The description mentions filtering by document, person, or status, which maps directly to the parameters but adds no new meaning beyond the schema. Baseline 3 applies.
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: 'Check who has signed a document and who hasn't.' It specifies filtering by document, person, or status, and the verb 'list' aligns with the name. It distinguishes from siblings like 'get-signing-request-tool' (singular) and 'send-signing-request-tool' (send vs list).
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 tracking compliance by checking signing statuses. It lists filtering options but does not explicitly state when NOT to use or mention alternatives like 'get-signing-request-tool' for single requests. However, the context of sibling tools provides some guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
send-reminder-toolSend Reminder ToolAInspect
Nudge someone who hasn't signed or acknowledged a document yet by sending them a reminder email.
| Name | Required | Description | Default |
|---|---|---|---|
| request_id | Yes | The ULID of the signing request to send a reminder for. |
Output Schema
| Name | Required | Description |
|---|---|---|
| message | Yes | |
| success | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate non-read-only, non-idempotent, non-destructive. Description adds external email side effect. Could be more explicit about whether it checks status before sending or about duplicate reminder handling.
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?
One sentence, no redundancy, front-loaded with action and target. Efficient.
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 one parameter, good schema, and existence of output schema, description is sufficient. Could mention prerequisites like existence of signing request, but not critical.
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 covers the single parameter with a clear description. Tool description provides context for use but no additional parameter details beyond schema. Baseline 3 for 100% coverage.
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?
Description clearly states it sends a reminder email to someone who hasn't signed or acknowledged a document. Distinct from sibling tools like send-signing-request (initial request) and cancel-signing-request.
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?
Description specifies it's for nudging those who haven't acted, implying after initial request. Lacks explicit when-not-to-use or alternatives, but condition is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
send-signing-request-toolSend Signing Request ToolAInspect
Send a document to one or more people to sign or acknowledge. Use this when a user wants their team or contacts to sign a policy, agreement, or compliance document.
| Name | Required | Description | Default |
|---|---|---|---|
| person_ids | Yes | Array of person ULIDs to send the request to. | |
| document_id | Yes | The ULID of the document to send. | |
| attestation_type | No | Override the attestation type: "acknowledgment" or "signature". Defaults to the document's default. |
Output Schema
| Name | Required | Description |
|---|---|---|
| requests | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already inform that the tool is non-readOnly, non-destructive, and non-idempotent. The description adds no additional behavioral context beyond the obvious write operation (sending). It does not discuss side effects, reversibility, or error states, but this is acceptable given the tool's straightforward nature.
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 two sentences: first states the core action, second provides usage context. Every word is necessary; no redundancy. It is front-loaded and efficient, earning the highest score.
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 the tool has an output schema and annotations, the description is largely complete. It covers the primary use case. Minor missing context (e.g., whether it triggers notifications) is not critical due to openWorldHint=true inferring possible external interactions.
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 100% with clear parameter descriptions. The description does not elaborate on parameters beyond implying document and people, but the schema already provides sufficient detail. The description adds no extra semantic value, earning a baseline score of 3.
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 action: 'Send a document to one or more people to sign or acknowledge.' It specifies the resource (document) and recipients, and distinguishes it from sibling tools like cancel-signing-request-tool and send-reminder-tool by focusing on initial sending of a signing request.
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 includes a usage guideline: 'Use this when a user wants their team or contacts to sign a policy, agreement, or compliance document.' This provides clear context but lacks explicit when-not-to-use instructions or alternative tool mentions, though siblings are listed separately.
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!