Federal government contracts and USAspending procurement exposure for SEC-listed companies.
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/5 across 8 of 8 tools scored. Lowest: 3/5.
Each tool targets a clearly distinct purpose: award_momentum finds changes in contract obligations, cluster_buys finds multiple insiders buying, contract_insider_overlap combines both datasets, federal_revenue_exposure tracks one company's awards, filings_feed provides raw Form 4 data, index_coverage reports data freshness, resolve_recipient maps contractor names to tickers, and screen_insider_buys ranks insider buying activity. No two tools overlap in function.
Tool names follow a generally consistent verb_noun pattern: award_momentum, cluster_buys, contract_insider_overlap, federal_revenue_exposure, filings_feed, index_coverage, resolve_recipient, screen_insider_buys. The verbs are descriptive (cluster, resolve, screen) and nouns are domain-specific. The only minor inconsistency is that award_momentum uses a noun_verb order rather than verb_noun, and filings_feed is not a verb+noun combination.
8 tools is a well-scoped count for a domain-specific MCP server that combines USAspending and SEC Form 4 data. Each tool covers a distinct analytical need without redundancy. The count is neither too thin to address the domain's complexity nor too heavy to navigate.
The tool set covers comprehensive workflows: searching by contractor name (resolve_recipient), by issuer (federal_revenue_exposure), screening across all companies (screen_insider_buys, award_momentum, cluster_buys), combining datasets (contract_insider_overlap), accessing raw data (filings_feed), and validating data coverage (index_coverage). There are no obvious gaps for the stated purpose of analyzing federal contract exposure and insider activity.
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?
Even without annotations, the description comprehensively discloses behavioral traits: that rankings are by issuer (not recipient name) with subsidiary roll-ups, that it uses USAspending data, and that quarter-to-quarter comparisons can be misleading due to multi-year obligations. This gives the agent full context on how the tool works and its data quirks.
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 front-loaded with the core purpose in the first sentence, followed by essential context (why issuer vs recipient matters), and concludes with a critical caveat. Every sentence adds unique value with no wasted words. It's concise yet comprehensive.
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 no output schema and minimal parameter descriptions, the description provides rich behavioral transparency, usage guidelines, and limitations that fully compensate. The agent gets all needed context: what the tool does, how it differs from alternatives, data sources, and interpretative cautions. No gaps remain.
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%, but the description effectively compensates by explaining the tool's logic (quarter-over-quarter change) which clarifies the global behavior. The description does not explicitly explain the 'min_confidence' parameter, but the overall context of federal awards data and the detailed behavioral transparency give sufficient semantic grounding. The 'limit' and 'min_usd' are straightforward from their names and defaults, so the lack of param-specific docs is less harmful.
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 states the tool ranks US-listed issuers by change in federal contract obligations, specifying the metric (change between two most recent comparable quarters) and the resource (issuers with federal contracts). It distinguishes itself from sibling tools by focusing on federal contract momentum, which is unique among the listed siblings that cover insider buys, filings, and clusters.
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 ('find which public companies are gaining or losing federal business') and includes critical usage warnings: large swings often reflect award timing rather than business trajectory, and the tool should be used as a list of things to investigate, not conclusions. This provides clear guidance on limitations and appropriate use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
cluster_buysBInspectIssuers 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?
With no annotations, the description must fully disclose behavioral traits. It states that the tool returns participant names and roles, and implies a read-only operation. However, it does not explain how the parameters (days, limit, min_value, min_insiders) affect the results, what 'window' means, or whether the operation is idempotent. The core logic of finding clusters is clear, but parameter behavior is opaque.
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 wasted words. The first sentence states the core purpose, the second adds context, and the third describes the return value. However, it could be more structured by including parameter explanations in a concise manner. The brevity is a strength, but it sacrifices completeness.
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 four parameters with 0% schema coverage, no output schema, and no annotations, the description is incomplete. It does not explain parameter roles, output format (beyond 'names and roles'), or any constraints like pagination. An agent would lack sufficient information to invoke the tool correctly with non-default parameters.
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 by explaining parameter meaning. It does not mention any of the four parameters (days, limit, min_value, min_insiders) or their defaults. The description mentions 'three or more distinct insiders' but does not tie this to min_insiders. No parameter semantics are added beyond the 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 finds issuers where three or more distinct insiders bought on the open market within a window. It specifies the purpose (detecting cluster buying patterns) and distinguishes from sibling tools like screen_insider_buys (which likely screens individual buys) and contract_insider_overlap (different focus). The verb+resource combination is specific: 'Issuers where ... bought'.
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 claims this is 'the most informative pattern' but does not contrast with other sibling tools like screen_insider_buys or award_momentum. There is no mention of prerequisites, exclusions, or scenarios where this tool would be inappropriate.
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?
With no annotations provided, the description carries full burden and excels. It discloses: only open-market purchases (Form 4 code P) are counted, excluding grants/exercises etc.; counts are separate by insider type; co-occurence only, no implied knowledge; obligations are not revenue; and the index coverage is limited. These are all behavioral traits beyond a basic purpose statement.
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 three paragraphs: first defines core purpose and data combination, second details what counts are reported and what is excluded, third adds caveats and next-step advice. Every sentence adds value, but the description is moderately long (110+ words) and could be tightened without losing meaning. Front-loading purpose is good.
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 no output schema, so the description should outline return structure. It does mention 'separate counts' for officer/director/10%holder, which hints at output shape, but lacks specifics on other fields, pagination, or whether results include company names, dates, or dollar amounts. The caveats are good, but for a complex 5-param tool, more completeness on expected output 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% – no parameter descriptions exist in the schema. The tool description does not mention any of the 5 parameters (days, limit, min_award, min_confidnce, min_insider_buy) or explain their meaning/format/units. Even the concept of 'window' (days) is only implicitly referenced in 'same window'. The description adds nothing to help understand parameters beyond default values in 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 finds US-listed companies where insiders made open-market purchases while the company won federal contracts. It explains the data combination rationale (award data lacks insider info, Form 4 lacks customer info) and distinguishes the tool's unique output (separate counts for officer, director, 10% holder). This is a specific verb+resource+scope that differentiates 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?
No explicit guidance on when to use this tool versus siblings (e.g., screen_insider_buys, cluster_buys). The only usage hint is 'if result is empty, call index_coverage' regarding coverage limitations, which is helpful but insufficient. No conditions for choosing this over alternatives or prerequisite setup advice.
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?
No annotations are provided, so the description carries the full burden. It transparently describes the roll-up behavior, return fields (per-quarter obligations, trend, attributed entities with match method/confidence, agency concentration), and notes that 'Obligated amounts are agency obligations, not recognized revenue.' This gives a strong sense of what the tool does and does not do, though it lacks explicit statements about read-only behavior 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 efficiently structured—opening with purpose, then justifying the tool's value with real-world examples, and finally listing return fields. Every sentence serves a purpose; there is no fluff. It is longer than one sentence but warranted given the complexity of the roll-up concept.
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 lacking an output schema, the description enumerates the return contents (per-quarter obligations, trend, recipient entity details, agency concentration). This is sufficient for an agent to understand what data it will receive. The three parameters are well-documented in context. Minor missing elements like data source cadence or latency are not critical.
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% with each parameter already described in the input schema (ticker, quarters, min_confidence). The description adds contextual usage examples but does not enhance the semantic meaning beyond what the schema provides. For instance, min_confidence's explanation is nearly identical to the schema's. Baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns 'federal 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.' This specific verb-resource combination with the roll-up detail distinguishes it from sibling tools like 'award_momentum' or 'resolve_recipient'.
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 advises 'Use this for any question about a public company's government revenue, defense or agency exposure, or federal contract trend.' It also explains why not to use USAspending directly with concrete examples (Lockheed Martin, UnitedHealth). However, it does not mention when to avoid this tool or suggest alternatives among siblings, such as 'resolve_recipient' for lower-level recipient queries.
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?
No annotations are provided, so the description must fully disclose behavioral traits. It lists output enrichments but does not state whether the operation is read-only, if there are rate limits, pagination behavior, or what happens on empty results. For a tool with no annotations, this is insufficient transparency about safety and usage constraints.
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 what the tool provides (normalized transactions with computed values, flags, and link), followed by filter options. Every sentence adds essential information with no waste, achieving high conciseness.
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 adequately states the tool's output (enriched filings with link) and filter capabilities. However, it does not describe the output structure or return format in detail, which an agent would need to use the results correctly. This is a moderate gap.
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 5 parameters with only 20% coverage (only 'code' has a description). The description adds value by emphasizing that 'ticker', 'code', and 'min_value' are the key filters, but it does not clarify 'days' or 'limit' semantics beyond their defaults. This provides some help but leaves gaps for 3 out of 5 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 the tool provides normalized Form 4 transactions with enriched data (USD values, insider role, 10b5-1 status, SEC link). The verb 'Normalized' and resource 'Form 4 transactions' make the purpose specific. However, it does not explicitly differentiate itself from sibling tools like cluster_buys or screen_insider_buys, though the general feed nature is implied.
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 mentions three filter dimensions (ticker, transaction code, minimum value) but does not provide explicit guidance on when to use this tool versus alternatives like screen_insider_buys or cluster_buys. It implies usage for general insider filing retrieval, but lacks when-not-to-use or context for selection.
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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It reveals a critical behavioral trait: screening tools can fail quietly without errors, and this tool is designed to prevent that. It also implies the tool is a reliable, non-destructive read operation that returns a comprehensive summary, which is transparent and helpful for the agent.
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 exactly two sentences, each earning its place. The first sentence front-loads the purpose and content of the report. The second sentence provides critical usage guidance. There is no redundancy or unnecessary information. It is highly concise yet fully informative.
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 is complete. It details exactly what the report contains (date range, counts, last refresh time) and provides the vital context of when to use it. The agent can understand the tool's purpose, behavior, and usage without needing additional structured information.
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 there is no parameter detail to add. Schema description coverage is 100% (trivially). The description adds value by explaining what the tool will report, which is beyond the schema. With no parameters, a baseline of 4 is appropriate as the description compensates by clarifying the output expectations.
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 'Report exactly what the index covers' and lists specific items: Form 4 date range, filing days ingested, transaction and issuer counts, award period range, number of issuers with attributed awards, and last refresh time. This is a specific verb (report) with a clear resource (index coverage), and it naturally distinguishes itself from sibling tools like screen_insider_buys or award_momentum by being a meta-coverage check.
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, returning fewer rows rather than an error'—and warns against the risk of misinterpretation. This is a clear directive on when to use this tool versus relying on other screening results.
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?
With no annotations provided, the description carries full responsibility and excels. It reveals critical behaviors: the tool returns ticker, match method, confidence score, and explanation; it distinguishes 'no match found' from 'affirmatively has no listed parent'; and it lists specific examples of entities that correctly resolve to no ticker (national lab consortia, universities, private companies, foreign subsidiaries). This level of detail fully informs the agent about the tool's 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 organized into three concise paragraphs: purpose and usage, output summary, and important nuance with examples. Every sentence serves a purpose, there is no redundancy, and critical information is front-loaded. It is efficiently written.
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 covers purpose, usage, output components, and a key behavioral nuance. For a tool with one input, no output schema, and no annotations, it is nearly complete. However, it could be slightly more precise about output formats (e.g., confidence score range, match method options) to fully compensate for the missing 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?
Schema coverage is 100% with 'name' already well-described as 'Recipient legal name as it appears in federal award data' with an example. The description adds usage-oriented context (e.g., 'contractor name from a solicitation') but does not materially enhance parameter meaning beyond the schema. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool maps a federal award recipient to its US-listed parent issuer or definitively states no parent exists. It uses specific verb-resource language ('Map a federal award recipient's legal name to the US-listed issuer') and is distinct from siblings like federal_revenue_exposure or contract_insider_overlap, which deal with different aspects of federal contracting.
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 '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,' providing clear context. However, it does not mention when not to use this tool or suggest alternative sibling tools, which would have earned a 5.
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 provided, the description must convey behavioral traits. It explains the screening scope (all indexed US public companies, open-market, insider buying) and the default exclusion of 10b5-1 trades with a rationale. However, it does not clarify whether 'net' includes sells or only buys, nor does it explain the effect of the parameters beyond the one default rule. This is adequate but not comprehensive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences efficiently cover purpose, usage context, and a key behavioral detail. Information is front-loaded (purpose first), and there is no redundant or unnecessary text. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of 5 parameters with no schema descriptions and no output schema, the description is incomplete. It explains only one parameter's default, does not describe the return format or structure of results, and omits how parameters like days, limit, min_value, or officers_only affect the output. An agent would lack critical information to use the tool confidently.
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 should explain all parameters. Only the 'exclude_10b5_1' parameter is implicitly explained through the rule about default exclusion. The other four parameters (days, limit, min_value, officers_only) receive no explanation, leaving their semantics entirely to the agent's inference from names, 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 screens all indexed US public companies by net open-market insider buying and returns the strongest names ranked. It also specifies it is a supporting tool for when no ticker is known yet, effectively distinguishing its role from sibling tools that likely require a ticker input.
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', giving a clear condition for when to use it. It also explains that Rule 10b5-1 trades are excluded by default, which guides usage. However, it does not mention when not to use it or directly reference alternative sibling tools, leaving room for improvement.
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!