Skip to main content
Glama

Look up OAuth scopes

lookup-scope
Read-onlyIdempotent

Lists Tiendanube/Nuvemshop OAuth scopes and the resources each opens, or finds the scope for a resource, endpoint path, or name; use it to choose app scopes or debug 401/403 errors.

Instructions

List the OAuth scopes of Tiendanube / Nuvemshop apps and the resources each one opens, or find the scope for a resource, endpoint path or scope name. Use it when choosing the scopes of an app in the Partners Portal or debugging a 401/403.

Input Schema

NameRequiredDescriptionDefault
queryNoA scope ("write_fulfillment_orders"), a resource ("Draft Order") or a path ("/orders/{id}"). Empty lists every scope.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnly, idempotent, non-destructive and closed-world, so the safety profile is fully handled. The description adds only that results describe which resources a scope opens; it says nothing about result size, whether matching is fuzzy or exact, or how resource names map to paths.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences, no filler, with the capability front-loaded and the usage trigger second. Every clause earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a single optional-parameter, read-only lookup with no output schema, the definition covers what is returned at a conceptual level (scopes and the resources they open) and when to reach for it. Only the result shape and matching behavior are underspecified, which is a minor gap.

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?

Schema description coverage is 100% and the query parameter's accepted forms (scope name, resource, endpoint path, empty for all) are fully documented in the schema. The description adds no syntax or matching details beyond that, so baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource: listing OAuth scopes of Tiendanube/Nuvemshop apps and the resources each opens, plus reverse lookup by resource, path or scope name. This is clearly distinguishable from siblings like lookup-endpoint or search-docs.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly names when to use it: choosing app scopes in the Partners Portal or debugging a 401/403. It does not name an alternative tool or state exclusions, so it falls short of a 5, but the trigger context is concrete enough to route an agent.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.