Syracuse Company News
Server Details
Structured company & industry news for AI agents: typed, dated, source-linked events.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
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.
Tool Definition Quality
Average 3/5 across 4 of 4 tools scored. Lowest: 1.7/5.
Each tool targets a clearly distinct function: listing location groups, registering a user and getting an API key, fetching stories by industry/location, and fetching stories by organization. There is no overlap in purpose.
All tool names use lowercase snake_case but the naming patterns are inconsistent: 'location_groups_list' and 'stories_*_list' follow a noun_list pattern, while 'register_and_get_key_create' uses a verb phrase with two actions. This mix reduces predictability.
With 4 tools, the server covers core functionality: location data, account creation, and two story query methods. The scope is well-contained for a news API, and no tool feels superfluous.
The tool set provides only filtered story listings (by industry/location or by organization) and lacks a general search, single story retrieval, or CRUD operations. While the main workflows are supported, important gaps exist for deeper queries or story management.
Available Tools
4 toolslocation_groups_listDInspect
Location Groups are a way of grouping GeoNamesLocation entities into a simplified hierarchy.
They start from top-level regions using the United Nations M49 standard (Region/Sub-Region/Intermediate Region). The US is further broken down United States Census Bureau regions (e.g. East/West etc) and then into individual states. Certain other countries are also broken down into their states/provinces: AE, CA, CN, IN.
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | A page number within the paginated result set. | |
| page_size | No | Number of results to return per page. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits, but it only describes the data model. It does not mention pagination, read-only nature, or return format.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is a single paragraph that is not front-loaded with the tool's purpose. It spends words on background rather than actionable 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 is insufficient for a simple list tool. It lacks essential details about what the tool returns, how to use pagination, and any usage context.
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 baseline is 3. The description adds no additional meaning beyond the schema's 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?
Description explains the concept of Location Groups but does not explicitly state that the tool lists them. The verb 'list' is implied by the tool name, not the description.
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 on when to use this tool versus alternatives. The description does not mention any context or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
register_and_get_key_createAInspect
Creates a user account with the given email, sends a verification email, and returns an API token. Unverified users are limited to 30 queries/month; verified users can make 300/month for free. Drop us an email to tell us how you found the service and if you want more queries (see website footer)
| Name | Required | Description | Default |
|---|---|---|---|
| Yes | User email address |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavior. It discloses account creation, email sending, token return, and rate limits. However, it does not mention error handling, email uniqueness, or whether authentication is needed. Some gaps remain.
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, front-loaded with the core purpose. It is reasonably concise but includes some extra information about contacting for more queries, which slightly reduces 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?
For a registration tool with one parameter and no output schema, the description covers the workflow and key constraints (verification, rate limits). It lacks details on errors or edge cases but is fairly complete for its 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?
The single parameter 'email' is fully described in the schema (type, format, description). The description adds no additional parameter semantics beyond what the schema provides. Baseline score 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 registers a user with an email, sends verification email, and returns an API token. It distinguishes itself from sibling tools which are list tools for location groups and stories.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for account creation but does not explicitly state when to use this tool versus alternatives. It mentions rate limits but no direct comparison to siblings. Thus, usage guidance is implied but not explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
stories_industry_location_listBInspect
Stories by Industry/Location Simplified endpoint that runs the same logic as the main stories endpoint, with a restricted parameter set (only industry and location). Stories can either be
-- IndustrySectorUpdate
or activities in an organization's lifecycle. We track the following activities:
-- CorporateFinanceActivity: M&A, investments, stock purchases
-- PartnershipActivity: Partnership between 2 or more organizations. Often, companies describe their customers as their partners. This type of activity covers both genuine partnerships and customer/supplier relationships
-- RoleActivity: Key change in senior personnel, e.g. replacing CEO
-- LocationActivity: Opening or closing a new location (e.g. setting up in EMEA or shutting down a factory in a particular town)
-- ProductActivity: New product launches
-- AnalystRatingActivity: Updates from industry analysts
-- EquityActionsActivity: Stock repurchases, dividends etc
-- FinancialReportingActivity: Notice that an organization is going to announce its financials
-- FinancialsActivity: Information about company financials, e.g. revenue or EBITDA
-- IncidentActivity: Adverse incidents e.g. safety
-- LegalActivity: Lawsuits or activities that could lead to lawsuits, e.g. SEC investigations
-- MarketingActivity: e.g. launching a new advertising campaign
-- OperationsActivity: Company operations news, e.g. we are investing in a new product, or we have just completed an security audit
-- RecognitionActivity: e.g. we are delighted to announce that we won Agency of the Year
-- RegulatoryActivity: Legal or regulatory activity affecting this organizationg e.g. permit for drilling, or regulatory filing
Parameters:
include_provenance: Add a
source_auditfield to each story explaining how it was surfaced (source path, Typesense match score, and the entity that carried it). Defaults to false.industry: Industry name to filter by. Accepts multiple values.
industry_context: Optional context aspects to anchor the industry search in. Pass each aspect as a separate value (e.g. "Packaging" when searching for "Rigid Metal"). Applied to every value of
industryin the same request.location: Location group name or id (e.g. "texas", "india", "MidWest", "FR", "us-ca"). Not case sensitive. Accepts multiple values. They must each match an id or name from the location groups endpoint.
output: Output format. Defaults to "simple" (SimpleStory schema). Use "full" for the detailed response.
page: A page number within the paginated result set.
page_size: Number of results to return per page.
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | A page number within the paginated result set. | |
| output | No | Output format. Defaults to "simple" (SimpleStory schema). Use "full" for the detailed response. | |
| industry | No | Industry name to filter by. Accepts multiple values. | |
| location | No | Location group name or id (e.g. "texas", "india", "MidWest", "FR", "us-ca"). Not case sensitive. Accepts multiple values. They must each match an id or name from the [location groups](#/location-groups/location-groups_list) endpoint. | |
| page_size | No | Number of results to return per page. | |
| industry_context | No | Optional context aspects to anchor the industry search in. Pass each aspect as a separate value (e.g. "Packaging" when searching for "Rigid Metal"). Applied to every value of `industry` in the same request. | |
| include_provenance | No | Add a `source_audit` field to each story explaining how it was surfaced (source path, Typesense match score, and the entity that carried it). Defaults to false. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It transparently lists the types of stories returned (e.g., CorporateFinanceActivity, PartnershipActivity) and mentions the restricted parameter set. However, it does not disclose whether the tool is read-only, any authentication needs, or rate limits, leaving some behavioral gaps.
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 a clear summary, but the long list of activity types (13 bullet points) could be condensed or moved to a separate section. This verbosity reduces conciseness, though the structure is otherwise logical.
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 no output schema, the description should explain the return format more thoroughly. It mentions 'simple' and 'full' output but does not describe the SimpleStory schema or pagination details like metadata. The list of activity types is informative but does not compensate for missing 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 coverage is 100%, but the description adds value beyond the schema: it explains location case insensitivity and reference to location groups, gives an example for industry_context, and clarifies include_provenance behavior. Most parameters get helpful extra context.
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 is a simplified endpoint for stories filtered by industry and location. It distinguishes from the main stories endpoint by parameter restriction and lists story types. However, it does not explicitly name the main endpoint as a sibling, and the purpose could be more concise.
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 when only industry and location filters are needed ('Simplified endpoint'), but does not provide explicit when-to-use or when-not-to-use guidance. No alternatives are named, and there is no mention of prerequisites or contexts where this tool is inappropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
stories_organization_listBInspect
Stories by Organization Simplified endpoint that runs the same logic as the main stories endpoint, with a restricted parameter set (only org_name). Stories can either be
-- IndustrySectorUpdate
or activities in an organization's lifecycle. We track the following activities:
-- CorporateFinanceActivity: M&A, investments, stock purchases
-- PartnershipActivity: Partnership between 2 or more organizations. Often, companies describe their customers as their partners. This type of activity covers both genuine partnerships and customer/supplier relationships
-- RoleActivity: Key change in senior personnel, e.g. replacing CEO
-- LocationActivity: Opening or closing a new location (e.g. setting up in EMEA or shutting down a factory in a particular town)
-- ProductActivity: New product launches
-- AnalystRatingActivity: Updates from industry analysts
-- EquityActionsActivity: Stock repurchases, dividends etc
-- FinancialReportingActivity: Notice that an organization is going to announce its financials
-- FinancialsActivity: Information about company financials, e.g. revenue or EBITDA
-- IncidentActivity: Adverse incidents e.g. safety
-- LegalActivity: Lawsuits or activities that could lead to lawsuits, e.g. SEC investigations
-- MarketingActivity: e.g. launching a new advertising campaign
-- OperationsActivity: Company operations news, e.g. we are investing in a new product, or we have just completed an security audit
-- RecognitionActivity: e.g. we are delighted to announce that we won Agency of the Year
-- RegulatoryActivity: Legal or regulatory activity affecting this organizationg e.g. permit for drilling, or regulatory filing
Parameters:
org_name: Filter by organization name (partial match). (required)
output: Output format. Defaults to "simple" (SimpleStory schema). Use "full" for the detailed response.
page: A page number within the paginated result set.
page_size: Number of results to return per page.
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | A page number within the paginated result set. | |
| output | No | Output format. Defaults to "simple" (SimpleStory schema). Use "full" for the detailed response. | |
| org_name | Yes | Filter by organization name (partial match). | |
| page_size | No | Number of results to return per page. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It explains the tool returns stories categorized by activity types and mentions output formats (simple/full). It does not disclose authentication, rate limits, or side effects, and does not describe the response structure beyond activity types. Adequate but not thorough.
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 fairly long due to the extensive list of activity types with explanations. While structured and informative, it could be more concise. The front-loading is adequate (starts with purpose), but the list is verbose for a tool description.
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 the tool's purpose and parameters well, and lists returnable content types. However, without an output schema, it lacks detail on the structure of the returned stories (e.g., fields, nesting). The agent may need additional context to process the response 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 coverage is 100%, so baseline is 3. The description repeats schema information (partial match for org_name, enum for output, pagination). It adds minimal extra context beyond what the schema provides, such as naming the SimpleStory schema for 'simple' output. No substantial added value.
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 that the tool returns stories for a given organization with a restricted parameter set (only org_name). It details the types of activities covered, making the purpose specific. However, it does not explicitly differentiate from sibling tools like stories_industry_location_list, which may serve a similar purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for fetching organization-specific stories, and lists the activity types. However, it does not provide explicit guidance on when to use this tool versus alternatives (e.g., main stories endpoint or siblings), nor does it mention when not to use it.
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.
Discussions
No comments yet. Be the first to start the discussion!