Gateway between LLM agents and world data through eight tools and a bundled endpoint catalog.
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 4.3/5 across 11 of 11 tools scored. Lowest: 3.4/5.
All tools have clearly distinct purposes. Endpoint exploration (list_sources, list_toolsets, search_endpoints, describe_endpoint), data retrieval (call_endpoint, fetch_data, get_snapshot, get_timeseries), entity resolution (resolve_entity), and compliance (sugra_entity_lookup, sugra_entity_screen) are well-separated. No overlapping functionality.
Most tools follow a verb_noun pattern (list_sources, get_snapshot, call_endpoint). Two compliance tools (sugra_entity_lookup, sugra_entity_screen) use a 'sugra_entity_' prefix, which is consistent among themselves but slightly deviates from the main pattern. The naming is otherwise predictable.
11 tools is well-scoped for a financial data and compliance API. Each tool serves a distinct purpose, covering endpoint management, data retrieval, entity resolution, and compliance. The count is not excessive and feels complete.
The tool set covers the full lifecycle for its domain: discovering and describing endpoints, calling them directly or via convenience wrappers, retrieving structured data (snapshots and timeseries), resolving entities, and performing compliance lookups/screening. No obvious gaps are present.
call_endpointACall a Sugra API endpoint by operation_id from the bundled catalog.
Plan calls with describe_endpoint's agent_hints: duration_class "fast" usually responds in under ~2s, "slow" usually 1-5s and occasionally 15s+ on a cold upstream, "heavy" can exceed the gateway timeout - keep parallel calls within max_concurrency and prefer small batches. Bulk endpoints bill 1 request credit per body item. Failures return structured errors {error, reason, status_code, elapsed_ms, retry_hint}; after "upstream_timeout" a single retry often succeeds because the aborted attempt warms upstream caches.
| Name | Required | Description | Default |
|---|---|---|---|
| body | No | JSON request body for a POST operation, matching the request_body_schema returned by describe_endpoint(operation_id). Omit for GET operations. | |
| limit | No | ||
| fields | No | ||
| params | No | Query and path parameters for this operation_id. Keys and types are operation-specific - call describe_endpoint(operation_id) first to get the exact parameter names, types, and examples. Omit if the operation takes none. | |
| include_raw | No | ||
| operation_id | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate read-only, idempotent, non-destructive. Description adds rich behavioral details: duration classes (fast/slow/heavy), billing per body item for bulk endpoints, structured error response format, and retry advice. No contradiction 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 concise, well-structured with separate sentences for action, planning, behavior, and errors. Every sentence adds value, no repetition. Ideal length for an AI agent.
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 complexity (6 params, output schema exists), the description covers essential planning hints, concurrency limits, error handling, and billing. It appropriately directs to describe_endpoint for parameter specifics, making it complete.
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 only 33% (6 params, 2 have descriptions). Description adds context for body and params by referencing describe_endpoint, but limit, fields, include_raw remain unexplained. More param-level detail would improve usability.
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 calls a Sugra API endpoint by operation_id. It distinguishes from siblings like describe_endpoint by focusing on execution. The mention of duration classes and planning adds specificity.
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 guidance on using describe_endpoint for planning, batch sizes, and retry strategies. However, it does not explicitly contrast with alternative tools like fetch_data or get_snapshot, leaving some ambiguity about when this tool is preferred.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
describe_endpointADescribe one Sugra API endpoint by operation_id.
Includes agent_hints (duration_class fast/slow/heavy, max_concurrency,
bulk billing) so you can budget timeouts and parallelism before calling.
POST endpoints with a JSON body also carry request_body_schema (the
resolved JSON schema) - construct the body argument from it instead
of guessing key names.
| Name | Required | Description | Default |
|---|---|---|---|
| operation_id | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, destructiveHint, indicating a safe read operation. The description adds value by detailing the returned agent_hints (duration_class, max_concurrency, bulk billing) and request_body_schema, which is beyond what annotations provide.
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 three sentences: first states the core purpose, second adds agent_hints usage, third explains POST body schema. It is front-loaded with the most critical information and contains no unnecessary 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 simple interface (one parameter, output schema present), the description covers the purpose, key output contents, and usage guidance. It is complete enough for an agent to understand when and how to use the tool. Minor gaps like error conditions or explicit mention of output schema are mitigated by the existing 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?
The single parameter operation_id is not explicitly described in the description, relying on the tool name and purpose for context. Schema description coverage is 0%, so the description bears the burden. But the purpose is clear enough that an agent can infer operation_id is the endpoint identifier. A brief explanation would raise the score.
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 'Describe one Sugra API endpoint by operation_id', with a specific verb and resource. The contrast with sibling tool call_endpoint is clear from context, as describe_endpoint is for metadata retrieval, not execution.
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 usage guidance: use this tool to obtain agent_hints for budgeting timeouts/parallelism and to get request_body_schema for POST endpoints. It implicitly tells the agent to use this before calling endpoints. While it does not explicitly exclude alternatives like search_endpoints, the context is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
fetch_dataAOne-step fetch: find the best Sugra endpoint for the query and call it.
Combines search_endpoints + call_endpoint into a single round trip. Use this when you want data without manually picking an operation_id. The full search_endpoints + describe_endpoint + call_endpoint dance is still available when you need explicit control, but for most natural-language queries this tool is enough.
Behavior:
Search the bundled catalog for the query. Top match wins.
If the matched endpoint has required parameters and they are all
provided in params, call it and return the response.
If required parameters are missing, return the candidate endpoints
and the missing-params list so the LLM can retry with the correct
params dict on the next call.
Examples:
fetch_data("US CPI inflation", params={"series_id": "CPIAUCSL"})
→ calls /api/v1/fred/series/CPIAUCSL, returns observations.
fetch_data("Bitcoin price", params={"coin_id": "bitcoin"})
→ calls /api/v1/crypto/bitcoin/price.
fetch_data("Latest financial news")
→ news_latest has no required params, returns latest news directly.
| Name | Required | Description | Default |
|---|---|---|---|
| body | No | JSON body for an auto-selected POST operation; the tool returns the request_body_schema to fill when the match needs one. | |
| limit | No | ||
| query | Yes | ||
| fields | No | ||
| params | No | Parameters for the auto-selected endpoint. If omitted and the best-match endpoint has required parameters, the tool returns that endpoint's required_parameters and examples so you can retry with them filled in. | |
| include_raw | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description details the three-step behavior (search, check params, return result or candidate endpoints with missing-params list). This adds behavioral context beyond the annotations (readOnlyHint, idempotentHint, destructiveHint). 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 well-structured with bullet points for behavior and practical examples. Every sentence adds value, no fluff. Appropriate length for a tool with complex behavior.
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 complexity (6 parameters, multi-step behavior), the description provides a clear process and examples. It mentions an output schema exists. However, it could explain the 'body' parameter more explicitly. Still, it is sufficient for correct 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 description coverage is only 33%, and the description does not explain parameters like 'limit', 'fields', or 'include_raw' in detail. It covers 'query' and 'params' adequately but leaves others unaddressed. This partially compensates for the schema gap but not fully.
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 that fetch_data combines search_endpoints and call_endpoint into one round trip. It distinguishes from the alternative 'search_endpoints + describe_endpoint + call_endpoint dance' for when explicit control is needed. The verb 'fetch' and resource 'data' are clear.
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 explicit guidance: use this tool for most natural-language queries without manually picking an operation_id, and use the full dance when explicit control is needed. It also explains the behavior when parameters are missing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_snapshotAComposed current view of an entity via a named recipe.
Executes a fixed server-side recipe (company_snapshot, etf_snapshot, quote_snapshot, macro_indicator_snapshot, macro_calendar, earnings_snapshot, debt_snapshot) and returns one envelope with freshness, provenance, per-component coverage, and billing. Composed calls charge the recipe's fixed cost (1-2 units) from the daily quota. status "partial" means an optional component was unavailable - the present components are still trustworthy; honor the freshness block (stale=true means the data aged past its budget).
Args: recipe: Recipe name from the fixed manifest. entity: Entity dict from resolve_entity ({"namespace": ..., "ids": ...}).
| Name | Required | Description | Default |
|---|---|---|---|
| entity | Yes | ||
| recipe | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only, idempotent, and non-destructive. The description adds valuable behavioral context: calls charge a fixed cost from daily quota, and explains how to handle partial responses (partial status means trustworthy data with possible missing optional components) and staleness (honor freshness block). This goes 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 is concise and well-structured: opening sentence states purpose, followed by execution details, cost, handling of partial status, and then clear Args section. It is front-loaded with essential information and avoids redundancy, though the Args section slightly duplicates the schema.
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 output schema exists (so return format is covered), the description covers all key aspects: recipe execution, cost implications, partial response handling, and dependency on resolve_entity. It provides sufficient context 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?
Input schema has minimal descriptions (0% coverage in schema), but the description fully compensates by explaining both parameters: recipe is 'from the fixed manifest' with explicit examples, and entity is a dict from resolve_entity with the required structure. This provides complete guidance for correct invocation.
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: 'Composed current view of an entity via a named recipe.' It lists concrete recipe examples (company_snapshot, etc.) and explains the return envelope contents. The purpose is specific and distinguishes from siblings (e.g., get_timeseries gets time series, not snapshots).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides context on when to use this tool (when a fixed server-side snapshot is needed) but does not explicitly state when not to use it or name alternative tools. It implies usage through recipe names and references to resolve_entity, but lacks direct comparative guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_timeseriesABounded timeseries for an entity: price, macro_series, or etf_flows.
Returns points oldest-first with an explicit downsampling flag when the raw series exceeded max_points. etf_flows is filing-cadence (one point per SEC filing refresh), NOT per calendar day, so even a wide window yields a handful of points. Times are UTC. Costs 1 unit per call.
Args: metric: One of price / macro_series / etf_flows. entity: Entity dict from resolve_entity ({"namespace": ..., "ids": ...}). granularity: Requested point granularity (default "1d"). max_points: Hard cap on returned points (default 500).
| Name | Required | Description | Default |
|---|---|---|---|
| entity | Yes | ||
| metric | Yes | ||
| max_points | No | ||
| granularity | No | 1d |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint, idempotentHint, and destructiveHint, but the description adds behavioral details: returns points oldest-first, downsampling flag, UTC times, and cost. These go beyond the annotations and provide useful context for invocation decisions.
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 relatively concise, with a clear opening sentence and a structured Args list. Every sentence adds value, though the Args section partly repeats the schema. It is front-loaded with purpose and key details, but could be slightly more streamlined.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema (not evaluated here) and the tool's complexity, the description covers all four parameters, explains defaults, and notes special behaviors (downsampling, filing-cadence, UTC). It does not discuss error handling or edge cases, but 'bounded' implies constraints are handled. Reasonably complete.
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?
Despite 0% schema description coverage, the description's Args section clearly explains each parameter: metric (enum values), entity (dict from resolve_entity), granularity (default 1d), and max_points (default 500). This adds significant meaning beyond the bare schema, compensating for the lack of inline 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 'Bounded timeseries for an entity' and lists the three specific metrics (price, macro_series, etf_flows). It uses a specific verb-resource combination and adds scoping details like 'oldest-first' and UTC times. However, it does not explicitly distinguish from sibling tools like get_snapshot, leaving room for confusion.
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 some usage guidance, such as the note on etf_flows filing-cadence and the cost of 1 unit per call. It also mentions the entity input comes from resolve_entity. However, it lacks explicit when-to-use or when-not-to-use instructions, and does not reference alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_sourcesAList endpoint source families derived from catalog metadata.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, covering safety and idempotency. The description adds a minor detail about being derived from catalog metadata, but does not add significant behavioral context beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, short sentence that is front-loaded with the key verb and resource. Every word is necessary, and there is 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?
The tool is simple with no parameters and has an output schema (inferred from context). The description covers the basic purpose, and the output schema likely specifies the return format. No major gaps.
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 zero parameters, the baseline is 4. The description adds nothing about parameters, but no information is needed since there are none.
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 it lists endpoint source families derived from catalog metadata, with a specific verb and resource. It distinguishes itself from sibling tools like call_endpoint and describe_endpoint by focusing on listing metadata.
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. The description only states what it does, without any context on prerequisites, exclusions, or comparisons to sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_toolsetsAList endpoint groups available in the bundled catalog.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint, covering safety and side effects. The description adds 'bundled catalog' context but no further behavioral traits beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single concise sentence with no unnecessary words. Every part earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter tool with output schema and comprehensive annotations, the description is complete enough to understand the tool's purpose and behavior.
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?
No parameters exist, and schema coverage is 100%. The description adds no parameter info but none is needed; baseline 4 for zero-param tool.
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 'endpoint groups in the bundled catalog', distinguishing it from sibling tools like list_sources which lists sources.
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 when-to-use or alternatives guidance, but the purpose is simple enough that usage is implied. For a list tool with no parameters, explicit guidelines are less critical.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
resolve_entityAResolve free text to a canonical market or macro entity.
Turns a ticker, company name, macro indicator, coin, or currency pair into
the agent plane's {namespace, ids} entity for use with get_snapshot and
get_timeseries. A cross-namespace collision (e.g. a ticker that is both an
equity and a coin) returns status "ambiguous" with ranked candidates and
NEVER silently picks one; pass type_hint (e.g. "equity", "etf", "coin") to
narrow the universe. For compliance KYB lookups by LEI/VAT or sanctions
screening use sugra_entity_lookup / sugra_entity_screen instead - this tool
is for market-data entities.
Args: query: Free-form text - ticker, company, indicator, coin, or pair. type_hint: Optional namespace hint narrowing resolution.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | ||
| type_hint | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false. The description adds critical context: collisions never silently pick one and return 'ambiguous' with ranked candidates. Also mentions type_hint narrowing behavior.
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 (3 paragraphs) and front-loaded with the core purpose. Every sentence adds value—no redundancy or filler. Structure progresses from summary to details to disambiguation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present, the description doesn't need to detail return values. It covers the ambiguous case, type_hint usage, and explicitly links to sibling tools (get_snapshot, get_timeseries) for further actions. All essential information is included.
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?
Despite 0% schema coverage, the description explains both parameters: 'query' as free-form text (with examples: ticker, company, indicator, coin, pair) and 'type_hint' as optional namespace hint (examples: equity, etf, coin). This compensates well for missing schema 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 resolves free text to canonical market/macro entities and mentions specific use cases like ticker, company, etc. It distinguishes from siblings by specifying the output format '{namespace, ids}' and the ambiguous collision behavior.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says when to use (market-data entities) and when not to (compliance lookups, naming sugra_entity_lookup and sugra_entity_screen as alternatives). Also explains how to handle ambiguous results with type_hint.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_endpointsBSearch the bundled Sugra endpoint catalog by natural-language query.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| query | Yes | ||
| source | No | ||
| toolset | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint. The description adds minimal extra behavioral context (e.g., 'bundled Sugra endpoint catalog'). Does not contradict annotations, but also does not disclose additional traits like rate limits or result format.
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, concise sentence with no fluff. It is front-loaded with the key action. However, being extremely short leaves out useful details, so it is not maximally concise for the information it should convey.
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 4 parameters (0% schema coverage) and an existing output schema not described, the description fails to provide sufficient context for correct invocation. It does not explain the search scope, result behavior, or how parameters like limit affect output.
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 0%, so description must compensate. It only mentions 'natural-language query' which loosely maps to the query parameter, but provides no details on limit, source, toolset, or their semantics. The default values and nullable types are not explained.
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 uses specific verb 'search' and resource 'Sugra endpoint catalog', clearly distinguishing from siblings like call_endpoint or describe_endpoint. It explicitly states natural-language query capability, leaving no ambiguity about the tool's 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?
The description implies usage for finding endpoints via natural language, but does not provide explicit guidance on when or when not to use it relative to siblings like list_sources, sugra_entity_lookup, etc. No alternatives or exclusions are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
sugra_entity_lookupAResolve an entity by identifier and return its composed KYB envelope.
anchor is lei (Legal Entity Identifier, resolved via the GLEIF registry)
or vat (EU VAT number, validated via the EU VIES service). The result
weaves identity, a sanctions screening signal, and - on request - ownership
and adverse-media slices.
The screening verdict is a SCREENING SIGNAL, not a compliance determination,
and any PEP / adverse-media content is supplementary and non-comprehensive.
The disclaimer field carries this and is always present.
Output is COMPACT by default to protect the agent context budget:
{entity:{name, anchor, value, status, country}, screening:{status, top_matches:[...3], hit_count}, ids:{...}, disclaimer}. Pass include to
opt INTO fuller per-slice detail, e.g.
include=["ownership","adverse_media"] adds those slices in full form.
On a bad anchor or an API error this returns a clean {error, detail} dict
rather than raising, so the agent can branch on result.get("error").
Args:
anchor: Identifier type, one of lei or vat.
value: The identifier value (the 20-char LEI code or the VAT number).
include: Optional list of fuller slices to add, e.g.
["ownership", "adverse_media"]. Omit for the compact default.
| Name | Required | Description | Default |
|---|---|---|---|
| value | Yes | ||
| anchor | Yes | ||
| include | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description goes beyond annotations by clarifying that the screening verdict is a signal, not a compliance determination, and that PEP/adverse-media content is non-comprehensive. It also explains the compact default to protect context budget and the error handling behavior. 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 well-structured and informative, but slightly verbose. It front-loads the purpose and provides detailed parameter and output explanations. Could be trimmed slightly without losing clarity.
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 complexity, the description covers purpose, all parameters, output format (with and without include), error handling, and disclaimers. With an output schema present, the description is thorough and leaves no major gaps.
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 0% schema description coverage, the description compensates fully by explaining the meaning of each parameter (anchor types, value format, include slices) and providing examples. 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.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool resolves an entity by identifier and returns a composed KYB envelope. It specifies the anchor types (lei, vat) and outlines the result contents, making the purpose very specific and actionable.
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 guidance on when to use the tool (for entity resolution with optional slices) and how to control output via the include parameter. However, it lacks explicit differentiation from sibling tools like resolve_entity or sugra_entity_screen, which would strengthen the when-not-to-use advice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
sugra_entity_screenAScreen a person or organization name against the Sugra sanctions corpus.
Returns a SCREENING SIGNAL, not a compliance determination. Sugra is a
technology provider, not a sanctions authority or consumer reporting agency.
PEP and adverse-media coverage is supplementary and non-comprehensive - a
clear result is not proof of absence, and a hit is a candidate match to
review, not a finding.
Output is COMPACT to protect the agent context budget:
{status, matches:[{name, score, list, type}], disclaimer}. The verdict
status is one of clear, review, or hit. The heavy raw fields
(match rationale, source ids, publish dates) are dropped; use the Sugra API
directly when the full screening envelope is needed.
Args: name: The person or organization name to screen (required). country: Optional ISO 3166-1 alpha-2 country to narrow the match. dob: Optional date of birth (YYYY-MM-DD) for a person. nationality: Optional nationality to narrow the match.
| Name | Required | Description | Default |
|---|---|---|---|
| dob | No | ||
| name | Yes | ||
| country | No | ||
| nationality | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnlyHint, openWorldHint, idempotentHint, and destructiveHint. The description adds important behavioral context: output is compact to protect context budget, results may be incomplete (open-world), and PEP/adverse-media is supplementary and non-comprehensive. 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 well-structured with clear paragraphs, first stating purpose, then behavioral notes, then output format, then parameter descriptions. It is concise without excess, though the parameter list could be more terse.
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 complexity (sanctions screening) and the presence of annotations and an output schema, the description covers essential aspects: input parameters, output verdicts, limitations, and use cases. It is complete enough for an agent to use 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?
With schema description coverage at 0%, the description meaningfully explains each parameter: name (required), country (ISO 3166-1 alpha-2), dob (YYYY-MM-DD), nationality. This adds format and optionality hints beyond the schema's basic type information.
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 screens a name against the Sugra sanctions corpus, specifying the verb 'screen' and the resource. It distinguishes from siblings like 'sugra_entity_lookup' by focusing on screening for sanctions hits.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states it returns a screening signal, not a compliance determination, and advises that Sugra is not a sanctions authority. It also explains when to use the full API for more detail, providing clear context for agent decision-making.
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!
Sign in to create a connector for this server.