Federal contract exposure for listed companies, with subsidiary-to-issuer resolution.
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.1/5 across 8 of 8 tools scored. Lowest: 3.3/5.
Each tool has a clearly distinct purpose: award_momentum ranks by contract change, cluster_buys finds multiple insider buys, contract_insider_overlap combines both signals, federal_revenue_exposure gives single-company history, filings_feed provides raw data, index_coverage reports metadata, resolve_recipient maps names to tickers, and screen_insider_buys screens all companies. No two tools overlap in function.
Tool names are descriptive and use snake_case, but they lack a consistent grammatical pattern. Some are verb-noun (resolve_recipient, screen_insider_buys) while others are noun-noun compounds (award_momentum, contract_insider_overlap, filings_feed, index_coverage). This inconsistency may hinder an agent's ability to predict tool names.
With 8 tools, the server covers the core analytical needs for federal contract exposure and insider trading analysis without being bloated. Each tool serves a distinct purpose, and the count feels well-scoped for the domain.
The tool set covers the main workflows: ranking, screening, single-company details, insider patterns, overlap detection, raw filings, and name resolution. Minor gaps exist (e.g., no direct award search by agency or list of all covered tickers), but these can be worked around and do not hinder core functionality.
award_momentumAInspectRank US-listed issuers by the change in their federal contract obligations between the two most recent comparable quarters. Use to find which public companies are gaining or losing federal business.
Ranked by issuer rather than by recipient name, which requires rolling subsidiary entities up to a ticker. USAspending can rank recipient names but cannot tell you that Electric Boat and General Dynamics Land Systems are the same investable company.
Large swings frequently reflect award timing rather than business trajectory, because a single multi-year obligation lands entirely in one quarter. Treat this as a list of things to investigate, not conclusions.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| min_usd | No | Minimum obligations in either period. | |
| min_confidence | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses that the tool rolls subsidiaries up to a ticker, uses two most recent comparable quarters, and warns that large swings may reflect timing rather than business trajectory. However, it does not mention output format, rate limits, or data freshness. Given the complexity of the tool, the disclosed behavioral traits are substantial.
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: first paragraph defines purpose and use case, second explains the issuer vs recipient distinction, third adds an important caveat. Every sentence earns its place. No fluff or repetition. Front-loaded with the core action.
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 has three parameters, no output schema, and no annotations, the description provides good context on business logic and interpretation but fails to explain parameter semantics or output format. The description does not hint at what the result contains (e.g., columns, metrics). It is adequate for a basic understanding but leaves gaps for an AI agent to fully 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?
Schema description coverage is only 33% (only min_usd has a description). The description does not mention any parameters or explain what limit, min_usd, or min_confidence mean. Defaults are provided in the schema but the description adds no value to parameter understanding. For a tool with three parameters and low coverage, this is a significant gap.
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 ranks US-listed issuers by change in federal contract obligations between two most recent comparable quarters. It specifies the verb 'rank' and the resource 'issuers by change in obligations', and distinguishes from sibling tools like contract_insider_overlap by focusing on contract momentum. The second sentence explicitly states the use case: 'find which public companies are gaining or losing federal business.'
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 tells when to use the tool ('Use to find which public companies are gaining or losing federal business') and provides important caveats about interpreting results ('Large swings frequently reflect award timing... treat as a list of things to investigate'). It contrasts with USAspending's recipient-based ranking, but does not explicitly name sibling tools as alternatives. Still, the guidance is clear and actionable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
cluster_buysAInspectIssuers where three or more distinct insiders bought on the open market inside the same window. Several independent insiders acting alike is the most informative pattern in the Form 4 dataset. Returns participant names and roles so the caller can judge whether operators or outside holders are responsible.
| Name | Required | Description | Default |
|---|---|---|---|
| days | No | ||
| limit | No | ||
| min_value | No | ||
| min_insiders | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses that the tool returns participant names and roles to judge operator vs. outside holder behavior. However, it does not mention whether the tool is read-only, idempotent, or any potential rate limits. The behavioral profile is partially clear but lacks details on side effects or data freshness.
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 long with no fluff. The first sentence states the core function, the second provides the rationale, and the third describes the output value. Every sentence adds information, and the structure is logical and front-loaded.
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 has 4 parameters and no output schema, the description covers the return value (participant names and roles) and the basic logic. However, it omits details on the time window range, default values, and how the 'min_value' and 'limit' parameters affect results. For a moderately complex data analysis tool, more complete documentation of parameter effects and output structure is needed.
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 indirectly explains 'min_insiders' (≥3 distinct insiders) and 'days' (same window) but does not explicitly define 'min_value' (open market value threshold) or 'limit'. The purpose of each parameter is not fully described, leaving the agent to infer defaults and behavior. At least two parameters lack any meaningful explanation.
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 identifies issuers where three or more distinct insiders bought on the open market in the same window. It distinguishes this from generic insider buying tools by specifying the clustering condition and explaining why this pattern is informative. The verb 'cluster' and focus on multiple insiders sets it apart from siblings like 'screen_insider_buys'.
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 does not explicitly specify when to use this tool versus siblings. It implies the tool is for detecting strong insider signals, but no direct comparison or exclusion criteria are given. While the rationale ('most informative pattern') suggests a use case, more explicit guidance on when to choose this over alternatives like 'screen_insider_buys' or 'filings_feed' would improve clarity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
contract_insider_overlapAInspectUS-listed companies where insiders made open-market purchases in the same window the company was winning federal contract obligations. This requires both corpora at once: award data has no concept of an insider, and Form 4 data has no concept of a customer.
Officer, director, and 10-percent-holder purchases are reported as separate counts, because an outside fund accumulating is a materially different signal from an operating executive buying. Only open-market purchases (Form 4 code P) are counted; grants, option exercises, gifts, and tax-withholding dispositions are compensation mechanics and are excluded.
Co-occurrence only. An insider purchase during a period of award activity does not imply knowledge of those awards, and obligations are not revenue. If the result is empty, call index_coverage before concluding there is no activity: the insider index covers a limited number of filing days.
| Name | Required | Description | Default |
|---|---|---|---|
| days | No | ||
| limit | No | ||
| min_award | No | ||
| min_confidence | No | ||
| min_insider_buy | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Even without annotations, the description fully discloses behavioral traits: it only counts open-market purchases (Form 4 code P), excludes grants/options/gifts/tax-withholding, reports officer/director/10-percent-holder purchases as separate counts, and explicitly warns that co-occurrence does not imply knowledge and obligations are not revenue. This level of specificity far exceeds what annotations would typically convey.
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, with clear paragraph breaks for different aspects (overall purpose, purchase categories, co-occurrence caveats, empty result handling). Each sentence adds value. However, it is somewhat long and could benefit from tightening or bullet points for readability, though it remains effective.
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 (5 parameters, no output schema, no annotations), the description is largely complete in explaining the logic and caveats. It covers the data sources, exclusions, and an important troubleshooting step (calling index_coverage). It lacks explicit return value details (since no output schema) but the caveats partially compensate. Minor gap: no mention of the expected output format or example.
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% (no parameter docs in the schema), so the description must compensate. However, the description does not explain any of the five parameters (days, limit, min_award, min_confidence, min_insider_buy) explicitly. Some parameters are inferable from context (e.g., 'min_award' and 'min_insider_buy' relate to thresholds), but no defaults or semantics are clarified. A well-written description would describe each parameter's role.
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 identifies US-listed companies where insiders made open-market purchases during windows of federal contract award activity. It specifies the verb (identify/query), the resource (companies with overlapping insider purchases and federal awards), and distinguishes itself by explaining the need for both corpora, differentiating it from siblings like screen_insider_buys or award_momentum.
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 when-to-use guidance: it requires both corpora simultaneously. It gives a key exclusion instruction: if the result is empty, call index_coverage before concluding no activity, because the insider index covers limited filing days. It also clarifies nuances like co-occurrence not implying knowledge and obligations not being revenue. Sibling context (e.g., index_coverage) is leveraged for proper workflow.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
federal_revenue_exposureAInspectFederal contract obligations for one US-listed company over time, rolled up across every award recipient entity that belongs to it, including subsidiaries that file under completely different names. Use this for any question about a public company's government revenue, defense or agency exposure, or federal contract trend.
Why not query USAspending directly: award recipients and SEC issuers share no identifier, and large issuers receive most of their federal money under subsidiary names. Searching USAspending for 'Lockheed Martin' returns a small fraction of Lockheed's obligations because the majority arrive as 'Sikorsky Aircraft Corporation'. Searching for 'UnitedHealth' returns almost nothing because its federal book arrives as 'Optum Public Sector Solutions'. This tool resolves those roll-ups.
Returns per-quarter obligations, a trend measured against the mean of prior quarters, every attributed recipient entity with its match method and confidence, and awarding-agency concentration. Obligated amounts are agency obligations, not recognized revenue.
| Name | Required | Description | Default |
|---|---|---|---|
| ticker | Yes | Stock ticker, e.g. LMT, GD, UNH, LDOS. | |
| quarters | No | Number of quarterly windows to return. | |
| min_confidence | No | Minimum entity-match confidence. 0.9 admits only verified and exact-name matches; 0 includes inferred ones. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Since no annotations are provided, the description carries full responsibility for behavioral disclosure. It clearly states the tool returns per-quarter obligations, trend measurement, entity match details with confidence, and awarding-agency concentration. It also clarifies that obligated amounts are agency obligations, not recognized revenue—a critical nuance. No contradiction exists.
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 paragraphs. The first clearly states the tool's purpose and use cases. The second explains the rationale and differentiation. The third details return structure. Every sentence adds value, though it could be slightly more concise by merging the first two paragraphs. Still, it is well-structured and front-loaded.
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 3 parameters, no output schema, and no annotations, the description provides a thorough overview: it explains the data source (federal contract obligations, not recognized revenue), the roll-up logic, return fields (per-quarter obligations, trend, entities, match method, confidence, agency concentration), and the rationale for using the tool. It is complete enough for an AI agent to confidently invoke and interpret results.
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%, so the baseline is 3. The description adds some value by explaining the purpose of the min_confidence parameter (admit verified matches vs. include inferred ones), but does not add new meaning beyond what the schema already provides for ticker and quarters.
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 the tool retrieves federal contract obligations for a US-listed company over time, rolling up across all recipient entities including subsidiaries. This specific verb+resource combination distinguishes it from siblings like 'resolve_recipient' or 'contract_insider_overlap'.
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 says when to use this tool ('any question about a public company's government revenue, defense or agency exposure, or federal contract trend') and crucially explains why not to query USAspending directly, with concrete examples (Lockheed Martin vs. Sikorsky, UnitedHealth vs. Optum). This provides clear context for selecting this tool over alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
filings_feedBInspectNormalized Form 4 transactions with USD values computed, insider role resolved, 10b5-1 status flagged, and a link to the original SEC filing so any figure can be verified at source. Filter by ticker, transaction code, or minimum value.
| Name | Required | Description | Default |
|---|---|---|---|
| code | No | Form 4 code: P purchase, S sale, A grant, M exercise. | |
| days | No | ||
| limit | No | ||
| ticker | No | ||
| min_value | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries full burden. It discloses the output features (normalization, computed values, resolved role, 10b5-1 flag, source link) and filtering capability. However, it omits behavioral details like pagination, ordering, data freshness, or default behavior (which are partially in schema defaults but not explained).
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, front-loaded with the core value proposition and filter options. Every sentence is informative with no redundancy or 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 5 parameters, no output schema, and no annotations, the description covers the return value fields and some filters but lacks details on output structure, parameter formats, and usage boundaries. It is sufficient for a basic understanding but not fully 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 description coverage is low (20%, only 'code' described). The description mentions three filterable parameters (ticker, transaction code, minimum value) but does not explain 'days' or 'limit'. It adds some context beyond the schema but does not fully compensate for undocumented parameters.
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 provides 'Normalized Form 4 transactions' with enriched fields (USD values, insider role, 10b5-1 flag, SEC filing link). This differentiates it from sibling analytical tools like cluster_buys or screen_insider_buys, though it does not explicitly contrast with them.
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 lists filter options (ticker, transaction code, minimum value) but provides no guidance on when to use this tool versus alternatives. There is no mention of use cases, prerequisites, or scenarios where a sibling tool would be more appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
index_coverageAInspectReport exactly what the index covers: Form 4 date range and filing days ingested, transaction and issuer counts, award period range, number of issuers with attributed awards, and last refresh time.
Call this before treating a small or empty result as evidence of absence. Screening tools fail quietly, returning fewer rows rather than an error, so an agent that skips this step will misreport index depth as market fact.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses what the tool reports (date range, counts, etc.) but does not explicitly state behavioral traits such as idempotency, safety, or side effects. For a zero-parameter read tool, the omission is minor but still leaves some uncertainty.
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 paragraphs: the first clearly lists the report contents, the second provides critical usage guidance. Every sentence is purposeful and front-loaded with the core action. 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 has no parameters and no output schema, the description fully enumerates the return fields (date range, counts, etc.) and explains when to use it. The usage context is rich, making it complete for an agent to decide when and why to call this tool.
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 has zero parameters and 100% coverage, so the baseline is 3. The description does not add parameter-level detail, which is acceptable since there are no parameters to document.
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 starts with 'Report exactly what the index covers' and lists specific data points, making the verb and resource clear. It also distinguishes from sibling tools by explicitly warning that screening tools fail quietly, so this tool serves as a diagnostic before relying on screening 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 provides explicit guidance: 'Call this before treating a small or empty result as evidence of absence.' It explains why (screening tools fail quietly) and implies when not to use alternatives (when you need to verify index depth). This is strong conditional usage advice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
resolve_recipientAInspectMap a federal award recipient's legal name to the US-listed issuer that owns it, or state authoritatively that no listed parent exists. Use when you have a contractor name from a solicitation, award notice, or news story and need to know which public company it belongs to.
Returns the ticker, the match method, a confidence score, and a written explanation. Critically, it distinguishes 'no match found' from 'this affirmatively has no listed parent'. Recipients such as national laboratory operator consortia (Triad National Security, which runs Los Alamos), universities, companies taken private (ManTech, taken private by Carlyle in 2022), and US subsidiaries of foreign-listed parents (Marinette Marine, owned by Milan-listed Fincantieri) correctly resolve to no ticker. That is a real answer, not a gap, and it prevents attributing federal revenue to the wrong issuer.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Recipient legal name as it appears in federal award data, e.g. 'ELECTRIC BOAT CORPORATION'. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Given no annotations, the description carries the full burden. It discloses that the tool returns a ticker, match method, confidence score, and explanation. It transparently explains edge cases: entities like national lab consortia, universities, taken-private companies, and subsidiaries of foreign-listed parents correctly resolve to no ticker, which is an intentional outcome. This provides valuable behavioral context beyond a simple 'find parent' function.
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 paragraph of about 150 words. It front-loads the purpose and usage, then provides critical edge cases. While it is not wasteful, it could be more structured (e.g., bullet points for return values) to improve scanability. The information is efficient but slightly verbose for a tool with one parameter.
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?
Despite having no output schema and one parameter, the description thoroughly covers the tool's purpose, usage, return values (ticker, match method, confidence, explanation), and critical edge cases. It explains what 'no ticker' means and why certain entities resolve that way. For a simple tool, this is complete and leaves no ambiguity about how to use or interpret results.
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 100%, so baseline is 3. The description adds usage context (e.g., 'as it appears in federal award data') but does not provide additional detail about the parameter beyond what the schema already offers. The example 'ELECTRIC BOAT CORPORATION' is helpful but already present in the schema description. No extra parameter semantics beyond baseline.
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 ('Map') and resource ('federal award recipient's legal name to US-listed issuer'), and clearly distinguishes the tool's unique outcome: 'state authoritatively that no listed parent exists'. This differentiates it from sibling tools like 'award_momentum' or 'federal_revenue_exposure', which serve different purposes.
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 when to use the tool: 'when you have a contractor name from a solicitation, award notice, or news story and need to know which public company it belongs to'. It also explains the critical distinction between 'no match found' and 'affirmatively no listed parent', guiding the agent on result interpretation. However, it does not explicitly name when not to use the tool or provide alternatives, though sibling tools are different enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
screen_insider_buysAInspectScreen all indexed US public companies by net open-market insider buying and return the strongest names ranked. Supporting tool for when no ticker is known yet. Rule 10b5-1 planned trades are excluded by default because they were scheduled in advance and carry no information.
| Name | Required | Description | Default |
|---|---|---|---|
| days | No | ||
| limit | No | ||
| min_value | No | ||
| officers_only | No | ||
| exclude_10b5_1 | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses that Rule 10b5-1 planned trades are excluded by default because they carry no information, and that the tool screens and ranks names. It does not mention read-only status or return format, but the core behavioral traits are well communicated.
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?
Three sentences, each adding value: purpose, usage context, behavioral detail. Front-loaded with the primary action. No redundant or unnecessary 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?
The description explains the purpose and key exclusion logic, but lacks details on output format, ranking criteria, and parameter meanings. Given no output schema and five parameters, the description is adequate but not fully complete for an agent to invoke the tool without ambiguity.
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 mentions the exclusion of 10b5-1 trades (matching the exclude_10b5_1 parameter) but does not explain the other four parameters (days, limit, min_value, officers_only) or their semantics. The agent must infer from names alone, which is insufficient.
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: 'Screen all indexed US public companies by net open-market insider buying and return the strongest names ranked.' It uses a specific verb ('screen') and resource (US public companies), and differentiates from sibling tools by noting it's for when no ticker is known yet.
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 says 'Supporting tool for when no ticker is known yet,' providing clear context for usage. However, it does not explicitly state when not to use this tool or name specific alternatives, leaving room for more precise guidance.
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!