Verify US & international addresses and send physical mail (postcards, letters, checks) via Lob.
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.
Average 3.9/5 across 18 of 18 tools scored. Lowest: 3.3/5.
Every tool targets a distinct resource and action, with clear verb-noun names like create_address and verify_us_address. There is no overlapping functionality, and even similar operations (e.g., list for different resources) are distinct.
All tools share the 'lob_' prefix and follow a consistent verb_noun pattern (e.g., create_postcard, list_letters, verify_intl_address). Multi-word nouns use underscores, maintaining uniformity throughout.
With 18 tools, the set covers the primary mail fulfillment operations—address management, postcards, letters, checks, self-mailers, and address verification—without feeling bloated or sparse. The count is well-suited to the domain.
The tool set has notable gaps: no create_check or create_self_mailer, no cancel for letters or checks despite being referenced, no update/delete for addresses, and only list for templates. These missing operations will likely cause agent failures in common workflows.
lob_cancel_postcardCancel a scheduled postcardACancel a postcard before its send_date so it is never mailed (and not billed). Fails if the send window has passed. Lob API: DELETE /v1/postcards/{id}.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Postcard id (psc_…) to cancel. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the destructiveHint annotation, the description explains consequences: the postcard is never mailed and not billed. It also specifies the failure condition (send window passed), providing full behavioral disclosure.
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 essential action. No unnecessary words; 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?
For a simple cancel tool with one required parameter and no output schema, the description covers the necessary context: when to use, what happens, and failure condition. No additional information is needed.
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 100% schema description coverage, the schema already fully documents the 'id' parameter. The description adds no additional semantic value beyond what the schema provides.
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 'Cancel a postcard before its send_date', providing a clear verb and resource. It distinguishes itself from siblings (e.g., create, list, get) by focusing solely on the cancel operation.
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 gives a clear condition: use before send_date, and notes failure if the window has passed. While it does not explicitly list alternatives, the context among siblings (no other cancel tools) makes the guidance sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
lob_create_addressSave an address recordACreate a reusable saved address record (does NOT send any mail). Returns an address id (adr_…) usable as to/from in mail tools. Lob API: POST /v1/addresses.
| Name | Required | Description | Default |
|---|---|---|---|
| name | No | Recipient name (required unless `company` is set). | |
| company | No | ||
| address_zip | No | ZIP / postal code. | |
| description | No | Internal label for this address. | |
| address_city | No | ||
| address_line1 | Yes | Primary street address. | |
| address_line2 | No | Unit/suite/apt. | |
| address_state | No | 2-letter state/province code. | |
| address_country | No | 2-letter ISO country code. Defaults to US. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations include destructiveHint=true, but the description does not elaborate on this. It adds that the tool returns an address ID and references the API endpoint, which is helpful but does not substantially expand 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?
The description consists of two concise sentences that front-load the key purpose and clarification. Every word adds 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?
For a tool with 9 parameters and no output schema, the description covers the core function, side effects (no mail sent), and return format. It is mostly complete, though could mention idempotency or prerequisites.
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 78%, and the description does not add additional meaning for parameters. The description mentions the return value but not parameter specifics, so it provides minimal extra value over 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 'Create a reusable saved address record' and explicitly clarifies it does not send mail. It distinguishes from sibling tools like lob_create_letter by specifying the address is used as to/from in mail 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 explains the tool is for creating saved addresses without sending mail, and that the returned ID is usable in mail tools. This provides clear context but does not explicitly state when not to use it or list alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
lob_create_letterSend a letter (COSTS MONEY)A⚠️ SENDS A REAL LETTER and charges your Lob account (use a test_ key to avoid real mail/charges). to/from accept an address id (adr_…) or inline object. file accepts an HTML string, a hosted PDF/URL, or a template id (tmpl_…). color is required. Cancelable only before send_date. Lob API: POST /v1/letters.
| Name | Required | Description | Default |
|---|---|---|---|
| to | Yes | Either an existing address id (adr_…) or an inline address object. | |
| file | Yes | Letter body: HTML string, asset/PDF URL, or template id (tmpl_…). | |
| from | Yes | Return address (id or inline object). Required for letters. | |
| color | Yes | true = color printing, false = black & white. | |
| send_date | No | ISO-8601 date/time to schedule the send (future). Cancelable until then. | |
| description | No | Internal label. | |
| double_sided | No | Print on both sides. Default true. | |
| merge_variables | No | Key/value data merged into HTML templates. | |
| address_placement | No | Where the recipient address is placed. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds important behavioral context beyond the destructiveHint annotation: it warns about real charges, explains that test keys avoid real mail, and mentions cancelability. No contradictions with 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 very concise: three sentences with no fluff. Key information is front-loaded with the warning emoji, and technical details are efficiently presented with backticks.
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 9 parameters and no output schema, the description provides a solid overview: cost, test key, cancelability, parameter types, required fields. It does not list all optional parameters but the schema handles that. Leaves no major gaps for agent decision-making.
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 description's parameter notes (e.g., `to`/`from` accept id or inline object) are redundant. It does not add new meaning beyond the schema, so 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 'SENDS A REAL LETTER' which is a specific verb and resource. It also highlights the cost and test key usage, differentiating it from sibling tools like lob_create_postcard. The title further reinforces the purpose.
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?
Provides some guidelines: use a test_ key to avoid real charges, and cancelable only before send_date. However, it does not explicitly compare to sibling tools or state when to use this tool over alternatives like lob_create_postcard.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
lob_create_postcardSend a postcard (COSTS MONEY)A⚠️ SENDS A REAL POSTCARD and charges your Lob account (use a test_ key to avoid real mail/charges). to and from accept an existing address id (adr_…) or an inline address object. front/back accept an HTML string, a hosted asset URL, or a template id (tmpl_…). Cancelable only before send_date. Lob API: POST /v1/postcards.
| Name | Required | Description | Default |
|---|---|---|---|
| to | Yes | Either an existing address id (adr_…) or an inline address object. | |
| back | Yes | Back artwork: HTML string, asset URL, or template id (tmpl_…). | |
| from | No | Return address (id or inline object). Optional. | |
| size | No | Postcard size. Default 4x6. | |
| front | Yes | Front artwork: HTML string, asset URL, or template id (tmpl_…). | |
| mail_type | No | USPS mail class. | |
| send_date | No | ISO-8601 date/time to schedule the send (future). Cancelable until then. | |
| description | No | Internal label. | |
| merge_variables | No | Key/value data merged into HTML templates. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds significant behavioral context beyond the destructiveHint annotation: it warns about real costs, suggests using test keys for safety, explains cancellation only before send_date, and details parameter type flexibility (id vs inline, HTML vs URL vs template).
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 compact and front-loaded with the critical warning. Every sentence adds value, covering key behavioral notes, parameter flexibility, and cancellation policy without 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 complexity (9 params, no output schema), the description covers main behaviors and key parameters but omits details on the return value (e.g., created postcard object), size/mail_type options, and merge_variables. Schema fills some gaps but output information is missing.
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%, so the baseline is 3. The description reinforces parameter types (address id vs inline, artwork formats) and adds send_date cancelability note, but mostly restates schema info without much new meaning.
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 'SENDS A REAL POSTCARD and charges your Lob account', making the action and resource explicit. However, it does not differentiate from similar sibling tools like lob_create_letter, lacking explicit sibling distinction for a top score.
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 over alternatives such as lob_create_letter or lob_cancel_postcard. It only offers a caution about using test keys, not usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
lob_get_addressGet a saved addressARetrieve a single saved address record by id. Lob API: GET /v1/addresses/{id}.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Address id (adr_…). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the agent knows it's a safe read operation. The description adds the API endpoint but no additional behavioral details (e.g., auth requirements, rate limits, response format). The description 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 extremely concise: one sentence plus the API reference. Every word is necessary. No 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?
For a simple retrieval tool with one required parameter and no output schema, the description is mostly adequate. It states what the tool does and how to identify the address. However, it could mention what the response contains (the full address record) or what happens if the id is invalid.
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 schema has 100% coverage for the single parameter 'id' with a brief description. The tool description does not add any extra meaning or constraints 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 clearly states the action ('Retrieve'), the resource ('saved address'), and the method ('by id'). It also provides the API endpoint. This distinguishes it from siblings like lob_create_address or lob_list_addresses.
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 implicitly suggests using this tool when you have a specific address id, but it does not explicitly state when to use this over alternatives (e.g., lob_list_addresses). No usage context or prerequisites are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
lob_get_checkGet a checkARetrieve a single check by id, including amount, status, and check number. Lob API: GET /v1/checks/{id}.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Check id (chk_…). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint=true, so description's 'Retrieve' is consistent. Adds return field info but no additional behavioral traits beyond what annotations cover.
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, no wasted words. Efficiently communicates purpose and returns.
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?
Adequate for a simple retrieval tool with one parameter. Mentions key return fields but could specify more about output format or error cases.
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 description adds no extra meaning beyond the schema's 'Check id (chk_…)'. Baseline score 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?
Clearly states 'Retrieve a single check by id', specifying the resource and action. Mentions return fields (amount, status, check number), and distinguishes from siblings like lob_list_checks which are for listing.
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 when to use: when needing details of a single check. No explicit exclusions or alternatives, but context from siblings (list, other resources) makes it clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
lob_get_letterGet a letterARetrieve a single letter by id, including status, PDF url, and tracking. Lob API: GET /v1/letters/{id}.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Letter id (ltr_…). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide readOnlyHint=true, which is consistent. The description adds the HTTP method (GET) via the API endpoint, providing a behavioral detail. No additional behavioral traits like authentication or rate limits are mentioned, which is acceptable for a simple read operation.
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: one sentence with core purpose plus the API endpoint. It front-loads the action and result, with 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 simple retrieval tool with no output schema, the description covers purpose, input (by ID), and output fields (status, PDF, tracking). It does not mention error handling but provides sufficient context for an agent to understand the return values.
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% for the single parameter 'id', so baseline is 3. The description does not add extra semantic meaning beyond the schema; it merely reiterates 'by id'. No examples or format details beyond the schema's description.
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 uses the verb 'Retrieve' and specifies the resource 'a single letter' with included fields (status, PDF url, tracking). It distinguishes from siblings like lob_list_letters (returns many) and lob_create_letter (creates). Also includes the explicit API endpoint.
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: when you need a single letter by its ID. While it does not explicitly compare with alternatives or state prerequisites, the simplicity of the tool makes the intended use clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
lob_get_postcardGet a postcardARetrieve a single postcard by id, including status, PDF url, and expected delivery. Lob API: GET /v1/postcards/{id}.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Postcard id (psc_…). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description is consistent with the readOnlyHint annotation (read operation). It adds context about the API endpoint and the returned data, which helps the agent understand behavior. No contradictions.
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 front-loads the purpose and includes key details. Every word earns its place; no 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 the simple tool (one required param, no output schema), the description adequately covers what the tool returns. No need for more detail.
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 param 'id' has a clear description in the schema (Postcard id format). Since schema coverage is 100%, the description adds no additional parameter semantics beyond restating 'by id'. 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 verb 'Retrieve' and resource 'a single postcard by id', and specifies returned fields (status, PDF url, delivery). It distinguishes from sibling tools like lob_list_postcards (list) and lob_cancel_postcard (different action).
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 using this tool when you need a specific postcard, but it does not explicitly mention when to use it over alternatives (e.g., lob_list_postcards for multiple). No exclusions or prerequisites are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
lob_list_addressesList saved addressesAList saved address records, newest first. Lob API: GET /v1/addresses.
| Name | Required | Description | Default |
|---|---|---|---|
| after | No | Cursor for the next page (from a previous response's next_url). | |
| limit | No | Max results per page (1–100). Default 10. | |
| before | No | Cursor for the previous page (from a previous response's previous_url). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true, so no destructive behavior. The description adds 'newest first' ordering and the API endpoint but does not disclose pagination behavior beyond what the schema parameters imply, nor rate limits or authentication needs.
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: one for purpose/ordering, one for API endpoint. No fluff, front-loaded with key action and resource.
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?
Lacks details on response format or return fields, which is not covered by output schema (absent). For a simple list operation with pagination parameters, the description is minimal but functional.
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 all three parameters with clear descriptions (cursor-based pagination, limit). The description adds no extra parameter information. With 100% schema coverage, baseline is 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 verb 'List' and the resource 'saved address records', and specifies ordering 'newest first'. This clearly distinguishes it from sibling tools like lob_get_address (single address) and lob_create_address (creation).
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?
No guidance on when to use this tool versus alternatives such as lob_get_address for a single address or lob_list_letters for other resources. The description does not mention exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
lob_list_checksList checksBList sent/scheduled checks, newest first. Lob API: GET /v1/checks.
| Name | Required | Description | Default |
|---|---|---|---|
| after | No | Cursor for the next page (from a previous response's next_url). | |
| limit | No | Max results per page (1–100). Default 10. | |
| before | No | Cursor for the previous page (from a previous response's previous_url). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true; description adds ordering info ('newest first') but does not explain pagination behavior or rate limits.
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, no wasted words, though the API reference sentence adds little 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?
Lacks explanation of return structure or pagination details; without output schema, description should provide more context.
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 all parameters with descriptions; description adds no additional parameter meaning beyond typical 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 clearly states the tool lists sent/scheduled checks with newest first ordering, distinguishing it from sibling tools like lob_list_letters.
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?
No guidance on when to use this tool vs alternatives, no exclusion criteria or context provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
lob_list_lettersList lettersAList sent/scheduled letters, newest first. Lob API: GET /v1/letters.
| Name | Required | Description | Default |
|---|---|---|---|
| after | No | Cursor for the next page (from a previous response's next_url). | |
| limit | No | Max results per page (1–100). Default 10. | |
| before | No | Cursor for the previous page (from a previous response's previous_url). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the description's mention of 'list' is consistent. The description adds the ordering behavior ('newest first') but does not disclose pagination details (e.g., use of cursors) or response structure beyond the API path.
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, zero waste. First sentence conveys purpose and ordering; second provides the API reference. Front-loaded and 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 no output schema, a description of return format (e.g., array of letter objects, pagination links) would be helpful. The tool is simple but misses contextual details about what the response contains, though the schema partially covers pagination.
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%, so the description does not need to explain parameters. It adds no new meaning beyond the schema, mentioning only the order (not a parameter). This meets the baseline for high 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 specifies the action (list), resource (letters), and ordering (newest first). It distinguishes from sibling tools like lob_list_postcards or lob_list_checks by naming the specific resource type.
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 the tool is for retrieving a list of letters, but lacks explicit guidance on when to use it versus alternatives (e.g., get_letter for a single letter, or other list tools). No mention of prerequisites or contraindications.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
lob_list_postcardsList postcardsAList sent/scheduled postcards, newest first. Lob API: GET /v1/postcards.
| Name | Required | Description | Default |
|---|---|---|---|
| after | No | Cursor for the next page (from a previous response's next_url). | |
| limit | No | Max results per page (1–100). Default 10. | |
| before | No | Cursor for the previous page (from a previous response's previous_url). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true, indicating a safe read operation. The description adds ordering detail ('newest first') and the API endpoint, enhancing transparency 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, highly efficient, and includes the API endpoint for debugging. Every word earns its place without 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?
For a list tool with three optional parameters and no output schema, the description is sufficient. It covers the key behavior (listing, ordering, API base) but could optionally mention response format.
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 the schema already describing all three parameters (after, limit, before). The description adds no additional parameter semantics beyond this.
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 verb 'List' and the resource 'sent/scheduled postcards', and specifies the order 'newest first'. This distinguishes it from siblings like lob_create_postcard and lob_cancel_postcard.
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?
No explicit guidance on when to use this tool versus other list tools (e.g., lob_list_letters). The resource is clear, but the description does not provide exclusion criteria or alternative suggestions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
lob_list_self_mailersList self-mailersAList sent/scheduled self-mailers, newest first. Lob API: GET /v1/self_mailers.
| Name | Required | Description | Default |
|---|---|---|---|
| after | No | Cursor for the next page (from a previous response's next_url). | |
| limit | No | Max results per page (1–100). Default 10. | |
| before | No | Cursor for the previous page (from a previous response's previous_url). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint=true, indicating a safe read operation. Description adds ordering detail ('newest first') and API endpoint reference, but no further behavioral traits like pagination behavior or data freshness are disclosed.
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 extremely concise: one sentence of purpose plus the API endpoint. No unnecessary words, front-loaded with 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?
Lacks output schema explanation and does not describe pagination behavior beyond default ordering. However, the API endpoint reference and schema cover key details. Adequate but leaves some context for the agent to infer.
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 3 parameters documented in schema). Description does not add any extra meaning beyond what the schema provides, meeting baseline expectations.
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 verb 'List' and resource 'self-mailers' with ordering 'newest first'. Distinguishes from sibling tools for other Lob resources (postcards, letters, etc.) by specifying 'self-mailers'.
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 listing sent or scheduled self-mailers but does not explicitly state when not to use or recommend alternatives. Scope is clear from the resource type, so it is easy to determine when to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
lob_list_templatesList templatesAList saved HTML templates usable as postcard/letter artwork. Lob API: GET /v1/templates.
| Name | Required | Description | Default |
|---|---|---|---|
| after | No | Cursor for the next page (from a previous response's next_url). | |
| limit | No | Max results per page (1–100). Default 10. | |
| before | No | Cursor for the previous page (from a previous response's previous_url). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnlyHint annotation already signals safe read behavior. The description adds context about the content (HTML templates for postcards/letters) and the API endpoint, but does not detail pagination or rate limits. With annotations covering the safety profile, the additional value is moderate.
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, no wasted words. Front-loaded with the core purpose and followed by the API endpoint. Extremely 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?
No output schema is provided, and the description does not explain the shape of the returned data (e.g., an array of template objects). However, the tool is simple and the purpose is clear; the missing output information is a gap but not critical for basic usage.
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%, so the baseline is 3. The description does not add any parameter-specific details beyond the schema's own descriptions of 'after', 'limit', and 'before'.
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 verb 'List' and the resource 'saved HTML templates', specifying their use as postcard/letter artwork. It also references the API endpoint, distinguishing it from sibling list tools (e.g., lob_list_addresses, lob_list_letters) which list different resource types.
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 the tool (to list saved templates for artwork), but does not explicitly exclude alternatives or provide when-not-to-use guidance. Given the simplicity of the operation, this is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
lob_us_autocompleteAutocomplete a US addressASuggest complete US addresses from a partial primary line — useful for address entry. Non-mutating. Lob API: POST /v1/us_autocompletions.
| Name | Required | Description | Default |
|---|---|---|---|
| city | No | Optional city to narrow suggestions. | |
| state | No | Optional 2-letter state to narrow suggestions. | |
| zip_code | No | Optional ZIP to narrow suggestions. | |
| address_prefix | Yes | Partial primary line, e.g. '185 Berr'. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds no new behavioral info beyond the readOnlyHint annotation; it repeats 'non-mutating' without detailing side effects, permissions, or error conditions.
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 with two focused sentences: the first states the purpose and usefulness, the second specifies non-mutating nature and the API endpoint. 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?
Given the low complexity, full schema coverage, and present annotations, the description adequately covers the tool's purpose and constraints. It lacks details on output format but that is acceptable without an 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?
All parameters have descriptions in the input schema (100% coverage). The description does not add further meaning beyond what the schema already provides.
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 verb 'suggest', the resource 'complete US addresses', and the scope 'from a partial primary line'. It distinguishes from sibling tools like verification and zip lookup by being for address entry autocompletion.
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?
Indicates 'useful for address entry' and that it is 'non-mutating', but does not explicitly state when to avoid using it or provide alternatives like verification tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
lob_us_zip_lookupLook up a US ZIP codeAReturn the cities and state associated with a US ZIP code. Non-mutating. Lob API: POST /v1/us_zip_lookups.
| Name | Required | Description | Default |
|---|---|---|---|
| zip_code | Yes | A 5-digit US ZIP code, e.g. '94107'. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, and the description reinforces with 'Non-mutating'. No additional behavioral traits (e.g., error handling, rate limits) are disclosed beyond the annotation.
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 efficient sentences front-load the purpose, omit extraneous details, and include API reference. 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?
With one parameter, read-only annotation, and no output schema, the description is mostly complete. Minor gap: does not explicitly state that multiple cities may be returned for one ZIP code, but overall adequate.
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 100% of parameter info, and the description adds no new meaning beyond the schema's '5-digit US ZIP code' example. 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 the tool returns 'cities and state associated with a US ZIP code', uses a specific verb 'look up', and distinguishes from siblings like verification or autocomplete tools via the 'Non-mutating' tag and API endpoint.
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?
No guidance on when to use this tool versus siblings such as lob_us_autocomplete or lob_verify_us_address. The 'Non-mutating' hint is implicit but does not provide explicit context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
lob_verify_intl_addressVerify an international addressAValidate & standardize a non-US address. country (2-letter ISO code) is required. Non-mutating (no mail sent). Lob API: POST /v1/intl_verifications.
| Name | Required | Description | Default |
|---|---|---|---|
| city | No | ||
| state | No | State / province / region. | |
| country | Yes | 2-letter ISO country code, e.g. 'GB', 'DE', 'CA'. | |
| postal_code | No | ||
| primary_line | Yes | Primary delivery line. | |
| secondary_line | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Description states 'Non-mutating (no mail sent)' and provides the API endpoint, adding context beyond annotations. Contradicts nothing and aligns with readOnlyHint=true.
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: first for purpose, second for required param and safety. No fluff; 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?
Minimally covers purpose, required param, and safety. Lacks details on return values (no output schema) and error handling, but adequate for a straightforward verification tool with good 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?
With only 50% schema description coverage, the description should compensate but only mentions the country parameter and its ISO requirement. Other parameters (city, state, postal_code) receive no description, limiting value.
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?
Clearly states the tool validates and standardizes non-US addresses. The verb-resource pair is specific and distinct from siblings like lob_verify_us_address.
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?
Specifies that the country parameter is required and clarifies the tool is non-mutating. Implicitly distinguishes from US-only verification via sibling names, though no explicit when-not-to-use guidance given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
lob_verify_us_addressVerify a US addressAValidate & standardize a US address, returning deliverability, corrected components, and a confidence score. Pass either a single freeform address string OR structured primary_line/city/state/zip_code. Non-mutating (no mail sent). Lob API: POST /v1/us_verifications.
| Name | Required | Description | Default |
|---|---|---|---|
| city | No | ||
| state | No | 2-letter state code, e.g. 'CA'. | |
| address | No | Freeform single-line address (alternative to the structured fields). | |
| zip_code | No | 5-digit or ZIP+4. | |
| primary_line | No | Primary delivery line, e.g. '210 King Street'. | |
| secondary_line | No | Secondary line, e.g. 'Suite 6100'. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide readOnlyHint: true, and the description adds 'Non-mutating (no mail sent),' which aligns. It further discloses that the tool returns deliverability, corrected components, and a confidence score, and it mentions the API endpoint. This adds value beyond the annotations without contradicting them.
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-loading the purpose and outputs. Every sentence adds value: the first explains what the tool does and returns, and the second specifies input modes and side effects. No filler or repetition.
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 no output schema and 6 parameters, the description explains what the tool returns and how to provide input. It covers the key behavioral aspects. However, it could briefly mention error scenarios or that the address must be US (though implied by the name). Overall, it is sufficiently complete for an AI agent.
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 83%, with most parameters having descriptions. The description adds semantics by clarifying the two input modes (freeform vs. structured) and implying that one set can be used exclusively. This helps the agent understand the relationship between parameters beyond the schema's individual descriptions.
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: 'Validate & standardize a US address, returning deliverability, corrected components, and a confidence score.' It specifies a specific verb ('validate & standardize'), a resource ('US address'), and distinct outputs. This differentiates it from siblings like lob_verify_intl_address and lob_us_autocomplete.
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 how to use the tool: pass either a freeform address string or structured components. It also notes that the tool is non-mutating. However, it does not explicitly state when to use this tool versus siblings like lob_us_autocomplete or lob_us_zip_lookup, nor does it provide exclusions or prerequisites.
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.
No comments yet. Be the first to start the discussion!