AI-powered startup due diligence. Screen any startup across 7 IMPACT-X dimensions, get a Sieve Score (0-140) with evidence-typed findings and a clear meeting recommendation. Built for VCs, solo GPs, and angel investors.
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.6/5 across 8 of 8 tools scored.
Each tool serves a distinct role in the screening workflow: dataroom listing vs adding, deal listing, screening, status polling, results retrieval, memo generation, and usage checking. No two tools have overlapping purposes.
All tools share the 'sieve_' prefix, but the pattern is inconsistent: some are pure nouns (sieve_deals, sieve_results), one combines resource and action (sieve_dataroom_add), and one is a verb (sieve_screen). Still, the names are readable and predictable once the domain is understood.
With 8 tools, the set is well-scoped and covers the entire lifecycle of a startup screening operation without unnecessary bloat. Each tool earns its place.
The core workflow is complete: add documents, screen, check status, retrieve results, generate memo, and list deals. Minor gaps exist, such as no update/delete for data room documents or a dedicated deal detail view, but agents can work around these.
sieve_dataroomAList all documents in a deal's data room.
Shows what files and content have been uploaded for a deal, along with their processing status.
Args: deal_id: The deal ID (from sieve_deals or sieve_dataroom_add).
| Name | Required | Description | Default |
|---|---|---|---|
| deal_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=true and destructiveHint=false, so the safe read-only nature is known. The description adds that the tool shows 'processing status', which is extra context beyond the annotations, but it does not disclose other behaviors like pagination or ordering. This is adequate but not rich.
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: a clear one-sentence summary followed by a brief elaboration and an arguments section. Every sentence carries meaning without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one param, read-only, output schema present), the description covers the essential purpose and parameter semantics. It could mention potential large result sets or filtering, but the output schema likely handles returns. It is sufficient for an agent to select and invoke 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 schema provides only a string type for deal_id with no description (0% schema coverage). The tool description compensates fully by explaining the meaning ('The deal ID') and telling where to get it ('from sieve_deals or sieve_dataroom_add'). This adds significant value beyond the raw 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 action ('List all documents'), the resource ('deal's data room'), and the outcome ('shows what files and content have been uploaded... along with their processing status'). This is specific and distinguishes it from sibling tools like sieve_dataroom_add (which adds documents) and sieve_deals (which lists deals).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use the tool (to list documents in a data room) and gives helpful guidance on obtaining the deal_id from sibling tools (sieve_deals or sieve_dataroom_add). It does not explicitly exclude alternatives, but the purpose is self-evident and the source hint for the parameter is useful.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
sieve_dataroom_addAInspectAdd a document to a deal's data room. Creates the deal if needed.
This is the primary way to get documents into Sieve for screening. Upload a pitch deck, financials, or any document -- then call sieve_screen to analyze everything in the data room.
Provide company_name to create a new deal (or find existing), or deal_id to add to an existing deal.
Provide exactly one content source: file_path (local file), text (raw text/markdown), or url (fetch from URL).
Args: title: Document title (e.g. "Pitch Deck Q1 2026"). company_name: Company name -- creates deal if new, finds existing if not. deal_id: Add to an existing deal (from sieve_deals or previous sieve_dataroom_add). website_url: Company website URL (used when creating a new deal). document_type: Type: 'pitch_deck', 'financials', 'legal', or 'other'. file_path: Path to a local file (PDF, DOCX, XLSX). The tool reads and uploads it. text: Raw text or markdown content (alternative to file). url: URL to fetch document from (alternative to file).
| Name | Required | Description | Default |
|---|---|---|---|
| url | No | ||
| text | No | ||
| title | Yes | ||
| deal_id | No | ||
| file_path | No | ||
| website_url | No | ||
| company_name | No | ||
| document_type | No | other |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds context beyond annotations by disclosing that the tool 'creates the deal if needed' and that file_path causes the tool to 'read and upload' the file. It does not explicitly address edge cases like providing both company_name and deal_id simultaneously, but the core behavioral traits of a write operation with deal-creation side effects are clearly conveyed, complementing the readOnlyHint=false annotation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is efficiently organized with a summary line, usage context, and a structured Args list. Every sentence adds functional value, and the format is scannable for an agent needing to select parameters quickly. The length is justified given the parameter count and side effects.
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 has 8 parameters, a mutation side effect, and a dual-mode deal targeting system. The description covers all essential aspects: main action, sequencing, parameter semantics, input constraints, and next steps. Since an output schema exists, the lack of return-value detail is acceptable. This description is self-sufficient for an agent to invoke 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 0% schema description coverage, the full burden falls on the tool description, and it delivers. The Args section explains every parameter, including purpose, accepted values, and relationships (e.g., 'creates deal if new, finds existing if not,' 'alternative to file,' 'used when creating a new deal'). This goes far beyond the schema's bare names and types.
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 a specific verb and resource: 'Add a document to a deal's data room.' It also states the key side effect ('Creates the deal if needed') and explicitly frames itself as 'the primary way to get documents into Sieve,' which distinguishes it from sibling tools like sieve_dataroom and sieve_deals.
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 clear when-to-use guidance ('This is the primary way to get documents into Sieve for screening') and directs the user to call sieve_screen afterward. It also explains alternative parameter paths (company_name vs deal_id, and the one-of content source requirement), effectively covering both tool-level and parameter-level usage decisions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
sieve_dealsAList deals in your Sieve pipeline.
Search by company name or list all deals. Returns deal metadata including Sieve scores for screened deals.
Args: search: Search by company name (partial match). Empty returns all. limit: Maximum results to return (1-100, default 20).
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| search | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate a read-only, non-destructive operation. The description adds behavioral details beyond annotations: partial match search, empty search returns all, and returned metadata includes Sieve scores. This enriches the agent's understanding without contradicting the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, front-loaded with the primary purpose, and each sentence adds value. It avoids redundancy and clearly separates the main description from parameter details, making it easy to scan.
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 listing tool with two optional parameters and an output schema, the description is largely complete. It covers purpose, parameters, and key behaviors. Minor gaps like pagination order or empty-result handling are not critical given the annotations and simplicity.
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 0%, so the description fully compensates by explaining each parameter: search is a partial company name match with empty returning all, and limit is capped at 1-100 with a default of 20. This adds meaningful constraints and behavior beyond the raw 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 opens with 'List deals in your Sieve pipeline,' which clearly identifies the action (list) and the resource (deals). It further specifies search options and return content, distinguishing it from siblings like sieve_screen (screening) or sieve_results (results).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains when to use the tool: to search by company name or list all deals. It does not explicitly name alternatives or exclusions, but the context is clear. Sibling tools are listed separately, and the description implies this is the go-to for deal listing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
sieve_memoAInspectGet or generate an investment memo for a deal.
If generate=false (default), retrieves the existing memo. If generate=true, creates a new memo (~15-30 seconds). Requires a completed screen.
Args: deal_id: The deal ID (from sieve_deals or sieve_screen). generate: Set to true to generate a new memo. memo_type: 'internal' (IC-facing, full risks) or 'external' (founder-facing). Default: internal.
| Name | Required | Description | Default |
|---|---|---|---|
| deal_id | Yes | ||
| generate | No | ||
| memo_type | No | internal |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses key behaviors beyond the annotations: the difference between retrieval (`generate=false`) and generation (`generate=true`), the ~15-30 second delay for generation, and the prerequisite of a completed screen. It also explains the `memo_type` semantics. It adds valuable context without contradicting the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured. It opens with a clear one-liner, then uses conditional statements for the dual behavior, and lists parameters with explanations. Every sentence adds value, and it avoids redundancy with 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?
For a tool with dual behavior and a prerequisite, the description covers the essentials: what it does, when to use it, and parameter details. However, it omits edge cases such as what happens if a memo already exists when generating, or if no memo is found when retrieving. The presence of an output schema reduces the need to describe return values, but slightly more behavioral edge-case info would increase completeness.
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 description provides thorough explanations for all three parameters beyond the schema: `deal_id` source, `generate` toggles behavior, and `memo_type` meanings. Since schema description coverage is 0%, this fully compensates for the lack of schema-level documentation.
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: 'Get or generate an investment memo for a deal.' It distinguishes between retrieval and generation with the `generate` flag, and the resource (memo for a deal) is specific. This uniquely differentiates it from sibling tools like `sieve_deals` or `sieve_screen`.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for usage: it requires a completed screen and specifies that `deal_id` comes from `sieve_deals` or `sieve_screen`, implying the workflow. However, it does not explicitly state when not to use this tool or compare it to alternatives, which would merit a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
sieve_resultsAGet the full results of a completed Sieve analysis.
Returns the Sieve Score (0-140), meeting decision (Take Meeting/Pass/ Need More Info), executive summary, key strengths, and key concerns.
Args: deal_id: The deal ID returned by sieve_screen. sections: Comma-separated filter (e.g. 'summary,strengths,concerns'). Options: summary, profiles, findings, questions, strengths, concerns. Empty returns everything. Score and decision are always included.
| Name | Required | Description | Default |
|---|---|---|---|
| deal_id | Yes | ||
| sections | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly and non-destructive. The description adds valuable behavioral details: score and decision are always included, empty sections returns everything, and the filter options. This goes beyond the structured 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 efficient and structured. The main capability is stated in the first sentence, followed by a concise list of return contents and a clear Args section. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (2 params, read-only), the description covers everything an agent needs: input origin, filter options, always-included fields, and return content. The output schema further reduces the need to describe return structure.
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 has zero descriptions, and the description fully compensates by explaining deal_id's origin and sections semantics (comma-separated, options, behavior). This adds substantial meaning 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 retrieves full results of a completed Sieve analysis, listing specific outputs (score, decision, summary, strengths, concerns). It distinguishes itself from sibling tools like sieve_screen (which produces the deal_id) by focusing on post-analysis result retrieval.
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?
It provides clear context: use after a completed Sieve analysis, with a deal_id obtained from sieve_screen. However, it does not explicitly name alternatives or when-not-to-use, though the 'completed' qualifier implies not for ongoing analyses.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
sieve_screenAInspectRun a Sieve IMPACT-X Quick Screen on a startup.
Analyzes the company across 7 dimensions (Innovators, Market, Product, Advantage, Commerce, Traction, X-Factor) and returns an analysis ID. Takes 2-5 minutes to complete. Upserts -- if the company was previously screened, returns the existing deal (set confirm=true to re-screen).
Two ways to use:
v3 (recommended): First add documents with sieve_dataroom_add, then call sieve_screen(deal_id=...) to analyze everything in the data room.
v2 (legacy): Call sieve_screen(company_name=..., website_url=...) directly. At least one of website_url or pitch_deck_text is required in this mode.
Args: company_name: Name of the startup to screen (v2 flow, or to create new deal). deal_id: Screen an existing deal by ID (v3 flow -- use after sieve_dataroom_add). website_url: Company website URL (v2 flow). pitch_deck_text: Extracted pitch deck text (v2 flow). description: Brief company description (optional). confirm: Set to true to re-screen an existing deal.
| Name | Required | Description | Default |
|---|---|---|---|
| confirm | No | ||
| deal_id | No | ||
| description | No | ||
| website_url | No | ||
| company_name | No | ||
| pitch_deck_text | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations (readOnlyHint=false, openWorldHint=true) are consistent with the description. The description goes beyond annotations by disclosing the upsert behavior, the 2-5 minute runtime, and that it returns an analysis ID. It also explains the re-screen behavior with confirm=true, providing valuable context about side effects without contradicting the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-organized and front-loaded with the core purpose. It uses a clear hierarchy: summary, key facts, usage modes, and argument details. Each sentence adds value with no redundancy, making it efficient despite covering complex functionality.
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—six parameters, two workflows, an output schema, and relationship to sibling tools—the description covers all necessary aspects: purpose, prerequisites, behavioral notes, arguments, and return value. It even references sieve_dataroom_add for the v3 flow, making it fully self-contained for selection and invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, but the description compensates fully with a detailed 'Args' section. Each parameter is explained with its usage flow (v2 vs v3), constraints (e.g., required fields), and optionality. This is essential since the schema alone provides no parameter descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Run a Sieve IMPACT-X Quick Screen on a startup.' It specifies the action, resource, and scope, and differentiates itself from siblings by describing two distinct workflows (v3 with deal_id and v2 with company details). This makes the purpose unambiguous and distinguishable from related tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on when and how to use the tool, including two usage modes with a clear recommendation (v3 first after sieve_dataroom_add, v2 as legacy). It also explains the condition for re-screening (confirm=true) and the requirement for at least one of website_url or pitch_deck_text in v2, giving agents clear decision-making criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
sieve_statusACheck the progress of a Sieve analysis.
Returns which IMPACT-X dimensions are complete with their scores, overall progress percentage, and current phase.
Args: deal_id: The deal ID returned by sieve_screen.
| Name | Required | Description | Default |
|---|---|---|---|
| deal_id | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare this as read-only and non-destructive. The description adds value by specifying exactly what information is returned (dimensions, scores, progress percentage, phase), which is not disclosed in the annotations. It does not contradict the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded. The first sentence states the purpose, the second explains the output, and the Args section adds necessary parameter context. There is no redundant fluff relative to 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?
With a single parameter, clear output description, and an output schema, the description is complete for an agent to select and invoke the tool. It provides enough context about the input source and expected results without needing additional explanation.
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 0%, so the description must compensate. It does so by explaining that deal_id is the ID returned by sieve_screen, providing important context for where to obtain the value. This is sufficient for a single simple parameter.
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: checking the progress of a Sieve analysis. It specifies the resource (Sieve analysis) and the action (check progress), distinguishing it from sibling tools like sieve_screen and sieve_results.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the usage context by stating the deal_id comes from sieve_screen, indicating this tool should be used after screening. However, it does not explicitly exclude alternatives or mention other tools for different purposes.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
sieve_usageACheck your Sieve API usage for the current billing period.
Shows screens used, monthly limit, tier, and organization name.
| 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=true and destructiveHint=false, providing the safety profile. The description adds the specific return fields (screens used, monthly limit, tier, organization name), which is useful but does not introduce deeper behavioral traits like pagination or rate limits. No contradictions exist.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences: the first states the purpose, the second lists what it shows. It is front-loaded and entirely waste-free, with no redundant phrasing.
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 read-only usage tool with an output schema present, the description sufficiently covers the tool's purpose and return content. There are no missing prerequisites or complex behaviors that would require further explanation.
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 description carries no parameter burden. It does not need to explain inputs, and the baseline of 4 applies. No additional parameter semantics are necessary.
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 specifies the verb 'Check' and the resource 'Sieve API usage for the current billing period', which distinguishes it from sibling tools like sieve_status (service status) and sieve_screen (screen-related). It is concise and unambiguous.
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 context: when you need to check API usage for the current billing period. It does not explicitly exclude alternatives or mention when not to use it, but the scope is clear enough for the agent to select it appropriately.
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!
