Syracuse Company News
Server Details
Syracuse is an MCP server that gives agents reliable company and industry/region news. Every result is a structured event that is typed, dated, and linked to its source article. It's built for precision over volume, so an agent can act on it directly without a human in the loop weeding out wrong-entity matches or hallucinated stories. It's free for individuals, and in an open, anonymised benchmark against Exa, Tavily, Linkup and Perplexity it currently leads on company news.
- 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.4/5 across 4 of 4 tools scored. Lowest: 2.5/5.
Each tool has a clearly distinct purpose: listing location groups, user registration, and two stories endpoints differentiated by filter (industry/location vs organization). No overlap.
Names use snake_case but patterns vary: location_groups_list follows noun_noun_verb, register_and_get_key_create starts with verb, stories_industry_location_list and stories_organization_list end with verb. Inconsistent verb placement and one tool uses multiple verbs.
4 tools is slightly below average but appropriate for a focused news API. It covers location reference, authentication, and two story queries—reasonable scope.
The tool set covers core use cases: querying stories by industry/location or by organization, listing location groups, and account registration. Missing a general unfiltered stories endpoint, but not critical.
Available Tools
4 toolslocation_groups_listCInspect
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?
No annotations provided. The description explains the hierarchy but does not disclose behavioral traits beyond that, such as pagination behavior, authentication requirements, or rate limits. For a list tool, these are significant 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 provides valuable context about the hierarchy but is somewhat lengthy and not front-loaded with the tool's core purpose. It could be more concise by starting with a direct statement of the tool's 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 no output schema and only two parameters, the description covers the conceptual background but lacks details on output format, error handling, or how to specify regions. An agent may struggle to use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Both parameters (page, page_size) have descriptions in the input schema, so schema coverage is 100%. The description does not add any additional meaning to these parameters, meeting the baseline but not exceeding it.
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 explains what Location Groups are and their hierarchy, but does not explicitly state that this tool lists them. The name 'location_groups_list' implies listing, but the description lacks a direct action statement like 'List all location groups'.
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 vs. siblings. The siblings are mostly stories-related, so this tool has a different domain, but there is no explicit advice on alternatives or 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.
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?
With no annotations, the description carries full burden. It discloses side effects (sends email, returns token) and rate limits (30/month unverified, 300/month verified). No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, no fluff, and packs essential information: action, outcome, limitations, and advice for more queries. Front-loaded and efficient.
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 a single parameter, no output schema, and no nested objects, the description is complete. It covers purpose, behavior, and limitations sufficiently for an AI to select and invoke the 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?
Schema already describes the email parameter with 'User email address' (100% coverage). The description adds context that the email is used for registration and verification, but does not enhance parameter-specific semantics 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 it creates a user account, sends a verification email, and returns an API token. It differentiates from sibling tools which deal with location groups and stories, not account registration.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides context for when to use (to register and get a token) and explains limits based on verification status. It implies a registration scenario but does not explicitly say when not to use or give alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
stories_industry_location_listAInspect
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?
With no annotations, the description carries the full burden. It lists 14 types of activities that stories can represent, providing rich behavioral context about the content. However, it does not mention important traits like pagination behavior, rate limits, or that it is a read-only operation, which would be expected for a list endpoint.
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 verbose, particularly the extensive list of activity types. While it is well-structured with bullet points, the length may reduce efficiency for an AI agent. It could be more concise by summarizing the activity list or moving details to an output schema.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 100% schema coverage and no output schema, the description adds useful context like linking location values to location_groups_list and explaining the types of stories. It is complete enough for a simple list-filter tool, though it could benefit from noting the default output format and pagination behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already covers 100% of parameter descriptions, so the description adds no critical new information for parameters. It does provide context on industry_context (applied to every industry) and references location_groups_list for location values, but overall the schema does the heavy lifting, earning a baseline 3.
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 filtered by industry and location, distinguishing it from sibling tools like stories_organization_list. It explicitly says it runs the same logic as the main stories endpoint but with a restricted parameter set, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use this tool (when only industry/location filters are needed) but does not explicitly compare it to alternatives like stories_organization_list. It provides clear context on the restricted parameter set, which helps an agent decide to use it over the full stories endpoint, but lacks explicit when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
stories_organization_listCInspect
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 provided, the description carries full burden. It lists many activity types, implying read-only behavior, but does not explicitly state that the tool is non-destructive, mention authentication requirements, rate limits, or pagination behavior beyond page parameters. The absence of critical behavioral disclosures limits transparency.
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 overly long due to a bulleted list of 14 activity types. The initial sentence is clear, but the list makes it verbose and less scannable. Critical usage guidance is missing, and the structure is not front-loaded with the most essential 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 covers the purpose and parameter meaning well, and the activity type list provides context on data content. However, it lacks details on return structure (no output schema), pagination limits, error handling, and prerequisites, leaving gaps for an AI agent to understand the full behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description repeats schema information for org_name, output, page, page_size, adding minor context like 'partial match' and default output format. The extensive list of activity types enriches understanding of the data but is not directly tied to 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's a 'Simplified endpoint that runs the same logic as the main stories endpoint' specifically for stories by organization. It lists the types of activities tracked. However, it does not differentiate from sibling tools like 'stories_industry_location_list' or 'location_groups_list', relying on the name alone for distinction.
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 it's a simplified version with a restricted parameter set, but provides no guidance on when to use this tool versus siblings (location_groups_list, register_and_get_key_create, stories_industry_location_list). No explicit when-to-use or when-not-to-use statements are present.
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!