Apideck Unified API MCP — 330 tools across 200+ SaaS connectors (accounting, CRM, HRIS, ATS).
Return the JSON-Schema input contract for a tool by name.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Exact tool name to describe (e.g. "accounting-invoices-create"), as returned by list_tools. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, aligning with the description's read-only return behavior. The description adds no extra behavioral context (e.g., performance, error conditions), so it meets baseline but doesn't exceed annotation coverage.
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, front-loaded sentence that communicates the exact purpose with zero redundancy. It is appropriately sized for a simple introspection tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (1 param, annotations safe, no output schema), the description fully explains what it returns and how to identify the target tool (via the param schema). It is complete enough for an agent to select and invoke correctly, though it could explicitly mention list_tools in the description itself.
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 'name' parameter well-described including an example and reference to list_tools. The description itself adds no parameter-level detail beyond the schema, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Return') and the resource ('JSON-Schema input contract') scoped by tool name, which distinguishes it from siblings like execute_tool (which executes) and list_tools (which lists tools). It precisely communicates what the tool does.
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?
Usage is implied: the tool retrieves a schema by name, and the schema's description references list_tools for exact names. However, the description itself does not explicitly state when to use this vs. alternatives (e.g., before execution) or provide exclusions, leaving the agent to infer context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Invoke a tool by name. input is forwarded raw to the tool handler.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Exact tool name to invoke (e.g. "accounting-invoices-create"), as returned by list_tools. | |
| input | No | Arguments object forwarded verbatim to the target tool. Its shape matches that tool's input schema (fetch it with describe_tool_input). Omit for tools that take no arguments. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate non-read-only, non-idempotent, non-destructive, open-world behavior. The description adds one behavioral detail: 'input is forwarded raw to the tool handler,' which clarifies that arguments are passed verbatim. However, it does not disclose that invoking arbitrary tools may have side effects or that return values vary—important context beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences, front-loaded with the action, and no unnecessary words. Every phrase earns its place: the first states the purpose, the second clarifies argument handling.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's generic dispatch nature and absence of an output schema, the description should mention return behavior or error outcomes, but it does not. The rich schema and annotations compensate partially, but the lack of return-value disclosure leaves a notable gap for an agent invoking unknown tools.
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 input parameter already explaining 'forwarded verbatim to the target tool' and referencing describe_tool_input. The description's 'input is forwarded raw' adds little beyond the schema, so it meets the baseline but does not elevate it.
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 function: 'Invoke a tool by name.' This specific verb+resource distinguishes it from sibling tools like list_tools (listing tools) and describe_tool_input (describing inputs). It is unambiguous and immediately identifies the tool as the execution dispatcher.
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—it is the tool to execute other tools—but provides no explicit 'when to use' or 'when not to use' guidance, nor does it name alternatives. The sibling context makes the role clear, but the description itself lacks explicit direction on selecting this tool over others.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return the list of allowed MCP scopes.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds 'allowed', which slightly clarifies scope constraints but does not disclose additional behavioral traits beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, clear sentence that immediately states the tool's purpose. No wasted words or redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple, parameterless, read-only tool with strong annotations and no output schema, the description adequately explains the return (a list) and the resource (MCP scopes). The simplicity of the tool does not require further elaboration.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the schema trivially covers all parameter semantics. Baseline 4 is appropriate for parameterless tools.
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 a specific verb ('Return') and names the resource ('the list of allowed MCP scopes'), clearly distinguishing it from sibling tools like list_tools or execute_tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives, nor any exclusions or prerequisites. It simply states the action 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.
Discover Apideck tools. Call with no args for domain index; filter with domain/search_terms/scope.
| Name | Required | Description | Default |
|---|---|---|---|
| scope | No | Filter by mutation scope: "read" (no writes), "write" (creates/updates), or "destructive" (deletes/overwrites). Omit to include all scopes. | |
| domain | No | Restrict results to a single tool domain (e.g. "accounting", "hris"). Omit to get the cross-domain index. Use a key returned by a prior no-arg call. | |
| search_terms | No | Case-insensitive substring terms ANDed across a tool name/description (e.g. ["invoice","create"]). Omit to list everything in the domain. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so the safety profile is established. The description adds behavioral detail about filtering and the domain-index behavior, but does not disclose return format, pagination, or rate limits. For a read-only discovery tool, this is adequate but not comprehensive.
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 short sentences that front-load the purpose ('Discover Apideck tools') and immediately provide usage instructions. It is concise, free of fluff, and every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple, with strong annotations and fully described parameters. The description covers invocation patterns clearly. However, given no output schema, it omits return-value details such as what the 'domain index' looks like or whether tool names/descriptions are returned. It is still sufficient for an agent to use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides 100% coverage with descriptive text for scope, domain, and search_terms. The description merely mentions the filter parameters by name without adding new semantic detail beyond what the schema already provides. It meets the baseline but does not augment it.
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 opens with 'Discover Apideck tools', a specific verb-resource pair that clearly states the tool's purpose. It differentiates from sibling tools like execute_tool and describe_tool_input by positioning this as the discovery entry point. The mention of 'domain index' and filtering further clarifies its scope.
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 explicit call patterns: 'Call with no args for domain index' and 'filter with domain/search_terms/scope'. It provides clear context on how to use the tool, though it does not explicitly state when not to use it or name alternatives like describe_tool_input for detailed schema inspection. This is clear context without exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
describe_tool_input2 fields changedInput schema / $schemaRemoved value: -"http://json-schema.org/draft-07/schema#"Input schema / properties / name / descriptionAdded value: +"Exact tool name to describe (e.g. \"accounting-invoices-create\"), as returned by list_tools."execute_tool7 fields changedInput schema / $schemaRemoved value: -"http://json-schema.org/draft-07/schema#"Input schema / properties / input / additionalPropertiesAdded value: +{}Input schema / properties / input / descriptionAdded value: +"Arguments object forwarded verbatim to the target tool. Its shape matches that tool's input schema (fetch it with describe_tool_input). Omit for tools that take no arguments."Input schema / properties / input / propertyNamesAdded value: +{
+ "type": "string"
+}Input schema / properties / input / typeAdded value: +"object"Input schema / properties / name / descriptionAdded value: +"Exact tool name to invoke (e.g. \"accounting-invoices-create\"), as returned by list_tools."Input schema / requiredPrevious value: -[
- "name",
- "input"
-]New value: +[
+ "name"
+]list_scopes2 fields changedInput schema / $schemaRemoved value: -"http://json-schema.org/draft-07/schema#"Input schema / requiredAdded value: +[]list_tools5 fields changedInput schema / $schemaRemoved value: -"http://json-schema.org/draft-07/schema#"Input schema / properties / domain / descriptionAdded value: +"Restrict results to a single tool domain (e.g. \"accounting\", \"hris\"). Omit to get the cross-domain index. Use a key returned by a prior no-arg call."Input schema / properties / scope / descriptionAdded value: +"Filter by mutation scope: \"read\" (no writes), \"write\" (creates/updates), or \"destructive\" (deletes/overwrites). Omit to include all scopes."Input schema / properties / search_terms / descriptionAdded value: +"Case-insensitive substring terms ANDed across a tool name/description (e.g. [\"invoice\",\"create\"]). Omit to list everything in the domain."Input schema / requiredAdded value: +[]describe_tool_input3 fields changedInput schema / properties / nameAdded value: +{
+ "type": "string"
+}Input schema / properties / tool_namesRemoved value: -{
- "description": "The names of the tools to describe",
- "items": {
- "type": "string"
- },
- "type": "array"
-}Input schema / requiredPrevious value: -[
- "tool_names"
-]New value: +[
+ "name"
+]execute_tool4 fields changedInput schema / properties / argumentsRemoved value: -{
- "additionalProperties": {},
- "description": "Arguments for the target tool as a JSON object, matching the schema returned by describe_tool_input.",
- "properties": {},
- "type": "object"
-}Input schema / properties / inputAdded value: +{}Input schema / properties / name / descriptionRemoved value: -"The name of the tool to execute"Input schema / requiredPrevious value: -[
- "name"
-]New value: +[
+ "name",
+ "input"
+]list_scopes1 field changedInput schema / $schemaAdded value: +"http://json-schema.org/draft-07/schema#"list_tools3 fields changedInput schema / properties / domainAdded value: +{
+ "type": "string"
+}Input schema / properties / scopeAdded value: +{
+ "enum": [
+ "read",
+ "write",
+ "destructive"
+ ],
+ "type": "string"
+}Input schema / properties / search_terms / descriptionRemoved value: -"Filter the list of tools.\nEach term is matched case-insensitively as a substring against tool name, description, and scopes.\nMultiple terms are combined with a logical OR: a tool is included if ANY term matches ANY field.\nIf not provided, all tools are returned."Claiming proves that you control a remote MCP connector. It does not move, proxy, or interrupt the server.
Open the connector listing, choose Claim ownership, and sign in to Glama.
Complete one verification method:
GitHub identity — fastest for official registry listings. For a namespace such as io.github.alice/server, link the matching GitHub user, then choose Claim with GitHub. An organization namespace such as io.github.acme/server also needs that organization to have installed the Glama AI GitHub App and approved its permissions, because GitHub discloses organization membership only to apps it has installed. Use HTTP or DNS when it has not.
HTTP challenge — works when you can deploy a public file. Generate a token, publish the exact JSON Glama shows at /.well-known/glama.json on the same origin as the connector, then choose Check HTTP challenge.
DNS challenge — works when you control DNS but cannot change the server. Generate a token, create the exact TXT record Glama shows, wait for it to propagate, then choose Check DNS challenge.
After verification, Glama sends a confirmation email and gives you access to listing details, thumbnails, health checks, and analytics. Keep the HTTP file or DNS record in place: Glama periodically checks it and ownership remains verified while the token is discoverable.
The HTTP ownership file has this structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"claim": "glama_claim_..."
}Claim tokens are opaque, stable, and bound to the signed-in Glama account. They contain no email address or other personal information. If Glama can no longer discover a verified HTTP or DNS token, it starts a seven-day grace period before removing claim-based access. Restore the same token during that period to keep ownership verified. Never publish an email address, Glama session token, GitHub token, or connector credential as ownership proof.
If verification fails, confirm that you copied the current token exactly. The HTTP file must be public, return valid JSON with a successful HTTP response, and stay on the connector's origin. DNS changes may need more time to propagate. A claim cannot transfer to a different origin or hostname: if the connector target changes, Glama starts the grace period and the new target must be claimed separately after the previous claim is released.
For a connector linked to the official MCP Registry, registry updates continue to replace its name, description, and URL by default. After claiming, open Manage connector and enable Use Glama listing details as the source of truth if edits made on Glama should be preserved. Categories and thumbnails are always managed on Glama; registry linkage and technical connection settings continue to sync.
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
To improve your MCP server's ranking:
Claim ownership of the server listing
Complete the server profile with an accurate description and thumbnail
Provide a test profile so Glama can connect to and evaluate the server
Keep tool definitions clear and complete to earn a high Tool Definition Quality Score (TDQS)
Route real usage through the Glama Gateway; more recorded successful server uses also improve the ranking
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!
Unified.to MCP server — one API for 500+ B2B SaaS integrations across 28+ categories
Authenticated, user-scoped MCP connectors for 30+ business systems.
Search, document and execute authenticated API calls across 700+ apps via one MCP server
Unified MCP server for 70+ eCommerce platforms: products, orders, customers, and more.
Add one secure layer between your agents and this server.
Each tool serves a distinct purpose: describe, execute, list scopes, list tools. There is no functional overlap, and an agent can easily select the right tool based on its name and description.
Tool names follow a verb_noun pattern with lower snake_case (e.g., list_tools, execute_tool). 'describe_tool_input' slightly deviates by combining 'tool' and 'input' as a compound object, but the overall pattern remains consistent.
With 4 tools, the server is well-scoped for its purpose as an MCP management interface, providing discovery, description, execution, and scope listing without unnecessary bloat.
The set covers the core operations for working with MCP tools: discovering tools, inspecting input schemas, executing them, and checking scopes. A minor gap is the lack of a dedicated tool for retrieving full tool metadata (beyond input schema), but this is workable.
