Square MCP Server

by block

Overview Schema Related Servers Score Discussions

Python

Remote

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v1.0.0
Disambiguation4/5
The tools are organized into clear domains (bookings, business, catalog, etc.), each with distinct purposes, reducing overlap. However, within some domains, operations like 'create' and 'update' across different resources might be conceptually similar, but the structured categorization helps differentiate them. There is minor potential for confusion in operations like 'search' vs 'list' across tools, but overall, the separation is effective.
Naming Consistency5/5
The tool names follow a highly consistent pattern: all are simple nouns (e.g., bookings, business, catalog) that correspond to Square API domains. Within each tool, operations use a consistent verb_noun format (e.g., create_booking, list_locations), with no mixing of conventions like camelCase or snake_case deviations. This uniformity makes the set predictable and easy to navigate.
Tool Count5/5
With 12 tools, the server is well-scoped for a comprehensive Square API integration, covering key business areas like payments, orders, inventory, and more. Each tool represents a distinct domain, and the count is appropriate for the broad functionality offered, avoiding both excessive fragmentation and insufficient coverage. It aligns with typical MCP server ranges for such APIs.
Completeness5/5
The tool set provides extensive coverage of Square's API domains, including CRUD operations for resources like bookings, customers, orders, and payments, as well as lifecycle management for subscriptions and invoices. There are no obvious gaps; each domain includes create, retrieve, update, delete, and search/list operations, ensuring agents can handle full workflows without dead ends.
Average 2.7/5 across 12 of 12 tools scored.
See the Tool Scores section below for per-tool breakdowns.
This repository is archived. Archived repositories automatically receive an F maintenance tier.
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions 'manage booking operations' which implies both read and write capabilities, but doesn't specify authentication requirements, rate limits, error conditions, or what happens during operations like 'cancel_booking'. For a tool with multiple operation types including destructive actions, this is insufficient behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is reasonably structured with clear categorization of operations, but could be more front-loaded. The initial 'Manage booking operations' line adds little value, and the formatting with bullet points is helpful but not optimally concise. Each operation listed earns its place by providing specific options, but the overall structure could better highlight the tool's core functionality first.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 2 parameters (one being a complex object), 0% schema description coverage, no annotations, and no output schema, the description is incomplete. While it documents the operation parameter well, it provides no information about the params dictionary structure, return values, error handling, or how this tool relates to sibling business tools. The absence of output schema means the description should ideally explain what the tool returns.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description provides significant value beyond the input schema, which has 0% description coverage. It enumerates 12 specific operation types organized into 4 categories, giving concrete meaning to the 'operation' parameter. While it doesn't detail the structure of the 'params' dictionary for each operation, the operation categorization adds substantial semantic context that the bare schema lacks.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Manage booking operations' which is a tautology that restates the tool name 'bookings'. While it lists specific operation types, it doesn't clearly articulate what the tool actually does - whether it creates, modifies, retrieves, or deletes booking data. The purpose remains vague rather than specifying a clear verb+resource combination.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus the sibling tools like 'orders', 'customers', or 'payments'. The description doesn't indicate what booking operations are distinct from other business operations, nor does it provide any context about prerequisites, appropriate scenarios, or limitations for using this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but offers minimal behavioral insight. It lists operation names but doesn't disclose whether operations are read-only or destructive, what permissions are needed, rate limits, or what happens during execution (e.g., side effects). The description is too vague to inform safe or effective use.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is structured with a brief header and a bulleted list, which is clear but not optimally front-loaded. The first sentence 'Manage catalog operations' is vague and doesn't immediately convey utility. However, it avoids unnecessary verbosity and the bullet list is efficient for listing operations.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (2 parameters with nested objects, no output schema, and no annotations), the description is incomplete. It lists operations but doesn't explain what they do, their inputs/outputs, or behavioral traits. For a tool with multiple operations and no structured guidance, this leaves critical gaps for an AI agent to use it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds significant value beyond the schema, which has 0% coverage. It enumerates 11 valid operations for the 'operation' parameter and explains that 'params' is a dictionary for operation-specific parameters. This compensates well for the schema's lack of descriptions, though it doesn't detail what each operation does or the structure of 'params'.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Manage catalog operations' which is tautological with the tool name 'catalog' and lacks a specific verb-resource combination. While it lists operation types, it doesn't clearly articulate what the tool fundamentally does or distinguish it from sibling tools like 'inventory' or 'orders'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The list of operations implies it's for catalog-related tasks, but there's no explicit context about prerequisites, when to choose specific operations, or how it differs from sibling tools like 'inventory' or 'products' (if present).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden for behavioral disclosure. The description mentions 'manage inventory operations' which implies both read and write capabilities, but doesn't specify which operations are destructive versus safe, what permissions are needed, rate limits, or what happens on success/failure. The Args section lists operation types but doesn't explain their behavioral differences or consequences.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is reasonably concise with a brief opening statement followed by structured Args section. However, the opening 'Manage inventory operations' adds little value, and the structure could be improved by front-loading more useful information about what the tool actually accomplishes rather than starting with a tautology.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 2 parameters, 0% schema coverage, no annotations, no output schema, and nested objects in parameters, the description is inadequate. While it documents operation types, it doesn't explain what each operation does, what the params dictionary should contain for each, what the tool returns, or how errors are handled. The description leaves too many open questions for effective tool use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage and 2 parameters, the description provides significant value by documenting the 'operation' parameter with 8 specific valid values. However, the 'params' parameter is described only as 'Dictionary of parameters for the specific operation' without detailing what those parameters might be for each operation type. This leaves substantial gaps in parameter understanding despite the operation enum documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Manage inventory operations' which is a tautology that essentially restates the tool name 'inventory'. While it lists specific operations in the Args section, the core description doesn't clearly articulate what the tool actually does beyond the generic term 'manage'. It doesn't distinguish this inventory tool from potential sibling inventory tools (though none are listed in siblings).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention any of the sibling tools (bookings, business, catalog, etc.) or explain what inventory operations are versus what those other tools handle. There's no context about when specific operations should be used or any prerequisites for using this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It mentions 'Manage business operations' which implies mutation capabilities, but doesn't disclose which operations are read-only vs. mutating, authentication requirements, rate limits, or error behaviors. The operation list suggests both read and write capabilities, but without behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with clear headings and bullet points. The two-sentence introduction is followed by organized parameter documentation. While somewhat lengthy due to the operation list, every element serves a purpose. Could be more front-loaded with a clearer purpose statement.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Inadequate for a complex multi-operation tool with no annotations and no output schema. The description doesn't explain what the tool returns, how errors are handled, or the scope of operations. For a tool that appears to be a gateway to multiple business subsystems, this leaves critical gaps in understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description compensates well by documenting the 'operation' parameter with a comprehensive list of valid values organized by category. It explains that 'params' is a dictionary for operation-specific parameters, though it doesn't detail what those parameters should contain. This adds significant value beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Manage business operations' which is vague and tautological with the tool name 'business'. It lists specific operations but doesn't clearly articulate what the tool actually does beyond being a multi-operation container. The purpose isn't distinguished from sibling tools like 'customers' or 'inventory'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 the sibling tools. While it lists available operations, it doesn't explain when to choose this multi-operation tool over more specialized sibling tools like 'customers', 'inventory', or 'orders'. No context about prerequisites or constraints is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. While it lists operations that imply various behaviors (create, delete, update, retrieve), it doesn't disclose any behavioral traits like authentication requirements, rate limits, side effects, or response formats. The description merely catalogs operations without explaining their behavioral implications.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is reasonably structured with an initial statement followed by organized parameter documentation. However, the operation list is quite lengthy and could benefit from better front-loading of key information. Some redundancy exists in the operation naming (e.g., 'customer' appears repeatedly in operation names).
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a complex tool with 2 parameters, no annotations, no output schema, and nested objects in parameters, the description is incomplete. While it documents operation values well, it lacks crucial information about authentication, error handling, response formats, and the structure of the 'params' dictionary. The agent would struggle to use this tool effectively without additional context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage and 2 parameters, the description provides substantial value by documenting the 'operation' parameter with a comprehensive list of valid values organized by category. It explains that 'params' is a dictionary for operation-specific parameters, though it doesn't detail what those parameters might be. This significantly compensates for the schema's lack of documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Manage customer operations' which provides a general purpose but is vague about what specific operations are available. It lists operations in the Args section, but the initial statement lacks specificity about the verb+resource relationship. It doesn't distinguish this tool from potential siblings like 'business' or 'orders' which might also manage customer-related data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention any prerequisites, context for choosing specific operations, or relationships to sibling tools. The agent must infer usage from the operation list alone without any when/when-not guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It lists operations like 'create_invoice' and 'delete_invoice' which imply mutations, but doesn't describe permissions, side effects, or response formats. Critical details such as whether deletions are permanent or if operations require authentication are missing, making it inadequate for a tool with multiple action types.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized and front-loaded with a brief purpose statement followed by a structured list of operations. Each sentence serves a clear function: the first sets context, and the second details parameters efficiently. There's no unnecessary verbosity, making it easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (multiple operations including mutations like delete), lack of annotations, no output schema, and nested parameters, the description is incomplete. It fails to explain behavioral traits, return values, or error handling, leaving gaps that could hinder an AI agent from using the tool correctly in varied contexts.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds significant value beyond the input schema, which has 0% coverage and only generic titles. It enumerates valid operations for the 'operation' parameter and explains that 'params' is a dictionary for operation-specific parameters. This clarifies the structure and purpose of both parameters, compensating well for the schema's lack of detail.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool 'Manage invoice operations' which provides a general purpose but lacks specificity about what 'manage' entails. It distinguishes from siblings like 'payments' or 'orders' by focusing on invoices, but doesn't clearly articulate the exact actions or resources involved beyond listing operations in the parameters section.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description lists operations but doesn't explain context, prerequisites, or exclusions. For example, it doesn't clarify if this should be used instead of sibling tools like 'payments' for invoice-related tasks, leaving usage ambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It mentions operations like 'create' and 'adjust' which imply mutations, but doesn't disclose permissions, side effects, rate limits, or response behavior. The description is minimal and lacks behavioral context needed for safe invocation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is efficiently structured with a brief purpose statement followed by clear parameter documentation using bullet points. Every sentence adds value, though it could be more front-loaded with a stronger purpose statement.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 2 parameters with nested objects, no annotations, and no output schema, the description is incomplete. It covers parameter semantics well but lacks critical behavioral details, output expectations, and error handling, making it inadequate for safe tool use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description compensates by detailing the 'operation' parameter with specific valid values categorized by type (Programs, Accounts, Promotions). It also explains that 'params' is a dictionary for operation-specific parameters, adding meaningful context beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool 'Manage loyalty operations' which gives a general purpose but lacks specificity about what 'manage' entails. It distinguishes from siblings like 'bookings' or 'payments' by focusing on loyalty, but doesn't clearly articulate the core function beyond a broad category.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description lists operations but doesn't explain context, prerequisites, or comparisons with sibling tools. Users must infer usage from the operation list alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but offers minimal behavioral insight. It lists operation types but doesn't disclose permissions needed, side effects (e.g., whether 'pay_order' charges a card), error handling, or response formats. For a tool with multiple operations including mutations, this is inadequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is efficiently structured with a brief header and organized bullet points for operations. Each sentence earns its place by listing operation categories and examples, though it could be more front-loaded with a clearer purpose statement.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (multiple operations including mutations), lack of annotations, no output schema, and nested parameters, the description is insufficient. It doesn't cover authentication needs, rate limits, error responses, or how to structure the 'params' dictionary for different operations, leaving critical gaps for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds significant value beyond the schema, which has 0% coverage. It enumerates valid operations for the 'operation' parameter and explains that 'params' is a dictionary for operation-specific parameters. This clarifies what would otherwise be completely undocumented parameters, though it doesn't detail the structure of 'params'.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool manages orders and checkout operations, which provides a general purpose but lacks specificity about what 'manage' entails. It distinguishes from siblings like 'bookings' or 'inventory' by focusing on orders, but doesn't clearly articulate the core verb beyond the generic 'manage'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like 'payments' or 'invoices'. The description lists operations but doesn't explain which scenarios warrant 'create_order' versus 'pay_order' or how this tool relates to sibling tools in the ecosystem.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It lists operations but fails to describe critical traits like authentication requirements, rate limits, error handling, or side effects (e.g., 'cancel_payment' might be irreversible). The description is operational but lacks transparency on how these actions behave in practice.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is structured with a brief overview and a categorized list of operations, which is front-loaded. However, it includes extensive bullet points that could be condensed, and some redundancy exists (e.g., listing all operations without summarizing). It's moderately efficient but could be more streamlined.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (multiple operation types, nested 'params' object) and lack of annotations and output schema, the description is incomplete. It covers operation options but omits details on parameter formats, return values, error cases, and integration context. For a tool with such broad functionality, this leaves the agent under-informed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds significant meaning beyond the input schema, which has 0% coverage. It enumerates valid operations for the 'operation' parameter and notes that 'params' is a dictionary for specific operations, clarifying their roles. However, it doesn't detail the structure of 'params' or provide examples, leaving gaps in parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose as managing payment operations using Square API, which is a specific verb+resource combination. It distinguishes itself from siblings like 'invoices' or 'orders' by focusing on payments, refunds, disputes, gift cards, and bank accounts. However, it doesn't explicitly contrast with all siblings, such as 'customers' or 'subscriptions', which might overlap in payment contexts.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It lists operations but doesn't explain scenarios for choosing 'payments' over sibling tools like 'invoices' or 'orders', nor does it mention prerequisites or exclusions. This leaves the agent without contextual usage cues.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It lists operation types but doesn't describe what these operations actually do behaviorally - whether they're read/write operations, what permissions are needed, what side effects occur, or how errors are handled. The description provides operation names but not their behavioral characteristics.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear categorization of operations and uses bullet points effectively. It's appropriately sized for a multi-operation tool, though the initial 'Manage team operations' line is somewhat redundant with the tool name. Each section earns its place by organizing the operation types logically.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a complex tool with 2 parameters, 0% schema coverage, no annotations, no output schema, and nested objects in parameters, the description is incomplete. While it documents operation values well, it doesn't explain the 'params' dictionary structure, return values, error conditions, or behavioral implications of different operations. This is inadequate for a multi-function mutation tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage and only 2 parameters, the description provides excellent semantic context for the 'operation' parameter by listing all valid operation values across four categories (Team Members, Wages, Labor, Cash Drawers). This significantly compensates for the schema's lack of documentation, though it doesn't explain the 'params' dictionary structure.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Manage team operations' which provides a general purpose but is vague about what specific resources are managed. It distinguishes from siblings like 'bookings' or 'customers' by focusing on team-related functions, but doesn't specify the exact verb+resource combination clearly beyond the broad 'manage' term.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus alternatives. The description lists operations but doesn't explain context, prerequisites, or when specific operations should be chosen. There's no mention of when-not-to-use scenarios or how this tool relates to sibling tools like 'business' or 'customers'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It lists operations but doesn't describe behavioral traits such as permissions required, rate limits, side effects (e.g., 'cancel_subscription' might be irreversible), or response formats. For a tool with multiple mutation operations (e.g., create, update, cancel), this lack of detail is a significant gap, though it at least implies the tool can perform both read and write actions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is structured with a brief purpose statement followed by a parameter list, which is front-loaded but could be more concise. The operation list is detailed but necessary given the schema gaps. However, the initial sentence 'Manage subscription operations' is somewhat vague and could be more specific, and the overall text is moderately efficient but not minimal.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (multiple operations with a nested 'params' object), no annotations, and no output schema, the description is partially complete. It covers the high-level purpose and parameter semantics adequately but lacks behavioral details, usage context, and output information. For a tool with such varied operations, more guidance on behavior and integration would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds substantial meaning beyond the input schema, which has 0% description coverage. It enumerates valid operations for the 'operation' parameter and explains that 'params' is a dictionary for operation-specific parameters, clarifying their roles. This compensates well for the schema's lack of descriptions, though it doesn't detail the structure or content of the 'params' dictionary for each operation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool's purpose as 'Manage subscription operations' which clearly indicates it handles subscription-related tasks. While it distinguishes itself from siblings like 'customers' or 'payments' by focusing on subscriptions, it doesn't specify what 'manage' entails beyond listing operations in the parameters section. The verb 'manage' is somewhat broad but the operational list provides concrete actions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'invoices' or 'orders' for related financial operations, or how it interacts with sibling tools. It lists operations but doesn't specify contexts, prerequisites, or exclusions for choosing this tool over others, leaving the agent to infer usage based on the operation names alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It lists operation types but doesn't describe what these operations do, their side effects, authentication requirements, rate limits, or error conditions. For example, it doesn't clarify that 'create_terminal_checkout' initiates a payment or that 'cancel_terminal_refund' might be irreversible. The description provides structure but minimal behavioral insight.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized but could be better structured. The opening sentence is clear, but the parameter documentation uses a bulleted list that might be less efficient than a table. All content is relevant, but it could be more front-loaded with a clearer summary of what 'manage' entails before diving into parameter details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (multiple operation types, nested params object) and lack of both annotations and output schema, the description is partially complete. It documents the parameter structure and valid operation values, which is essential, but doesn't explain what each operation does, what the params should contain, or what the tool returns. For a multi-operation tool with no other documentation, this leaves significant gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds significant value beyond the input schema, which has 0% description coverage. It explains that 'operation' accepts specific string values categorized into Checkout, Devices, and Refunds operations, and that 'params' is a dictionary for the chosen operation. This clarifies what would otherwise be completely undocumented parameters, though it doesn't detail what parameters each operation expects.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Manage Square Terminal operations' with a verb ('Manage') and resource ('Square Terminal operations'). It distinguishes from siblings by focusing specifically on Terminal operations rather than other Square services like bookings, payments, or customers. However, it doesn't specify what 'manage' entails beyond listing operation categories.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It lists operation categories but doesn't explain when to choose Terminal operations over other sibling tools like payments or orders, nor does it provide any context about prerequisites, typical use cases, or exclusions. The agent must infer usage from the operation list alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![square-mcp MCP server](https://glama.ai/mcp/servers/block/square-mcp/badges/card.svg)](https://glama.ai/mcp/servers/block/square-mcp)

Score Badge

Copy to your README.md:

[![square-mcp MCP server](https://glama.ai/mcp/servers/block/square-mcp/badges/score.svg)](https://glama.ai/mcp/servers/block/square-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/block/square-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server